Proposed resolution:

This wording is relative to N4971.

1. Modify [macro.names] as indicated:

   -1- If a translation unit includes a standard header, imports a standard header unit, or imports a standard library module, and provides a name specified in the standard library as an argument to #define or #undef, the program is ill-formed, no diagnostic requiredA translation unit that includes a standard library header shall not #define or #undef names declared in any standard library header.

   -2- A translation unit shall not #define or #undef names lexically identical to keywords, to the identifiers listed in Table [tab:lex.name.special], or to the attribute-tokens described in [dcl.attr], except that the names likely and unlikely may be defined as function-like macros ([cpp.replace]).

There are several places where the standard talks about what happens when including a header, and only sometimes do we address the notion of importing a header unit, or importing a standard library module. One global concern is that [macro.names] prohibits users defining macros with a name that matches a name from any standard library header, but only if a standard library header is included. We should maintain that same prohibition on importing a standard header unit, and importing a standard library module. In general, we probably want some front matter to address the include vs. import wording issue in one place, rather than trying to update every usage — if it is already there I could not find it. It is also likely that some uses will want to say specific things about import vs. include and those cases will be handed to audit for if we have blanket front-matter wording. I also question whether "shall not" is the right way to prohibit users defining macros in their own code. Must a "shall not" restriction be diagnosed? I think the "right" answer is to make the program ill-formed, no diagnostic required. That is a foul answer, but UB does not really fit as there is no actual behavior to be undefined, unless we mean the process of translating the program is undefined, in which case IFNDR is the better way to say that. If we expect implementations to diagnose users defining macros that match library names we should say so more clearly, but I am not aware of any current tool-chain that does so.