But macro names are identifiers (see definition of control-line in §16/1), aren't they?

@Arcoth There are two kinds of identifier. One is of preprocessing-token, the other is of token. Macro names live in phases before tokens are recognized. BTW, keyword of token comes from identifier of preprocessing-token.

It seems to me that [lex.name]/3 covers the general case of an identifier, not only the specific case of an identifier-as-a-token, so it also applies to macro names. Can you point to some specific wording that you find to be problematic here?

@zygoloid I don't think there are problems about the wording itself (as it in [lex.name] but not [lex.token]), but it might be clearer by adding some additional notes, or it can be placed elsewhere (i.e. [lex.pptoken]).
Two things are concerned:

• [lex.name]/2 mentions "to interpret the token", but not "preprocessing token". So at least in this paragraph, "identifier" is of token, which is no longer a macro name (and cannot be a keyword) in that context. This is not consistent with [lex.name]/3.
• [lex.key], which comes right after [lex.name], whose position also suggests the "identifier" in [lex.name] is of token rather than of preprocessing token.

@FrankHB [lex.name]/2 is referring to language (not preprocessing) tokens, hence it says "When referred to in the grammar." (BTW, "referred to" is an awkward dangling preposition. Perhaps "When specified literally ([syntax] §1.6)" would be better.)

@zygoloid The problem might be "In addition" in ¶3, which suggests that keywords and contextual keywords are not to be used as macro names. You can still use #define override or #define delete as long as no standard library header is included, per §17.6.4.3.1 [macro.names]. Perhaps the recent DR meant to strengthen that rule as well?

[lex.name]/3 should not say "in addition," because it does not connect to ¶2. However, it should have a [Note] at the end referencing [macro.names] and mentioning that keywords are not otherwise reserved as pp-tokens.

Also, [lex.name]/2 should be moved into [lex.key], since the contextual keywords are a special case of keywords, not a special case of the identifier pp-token production.

I disagree with "Also, [lex.name]/2 should be moved into [lex.key], since the contextual keywords are a special case of keywords, not a special case of the identifier pp-token production." The contextual keywords are, in fact, identifiers and initially parsed as such. Only when the (parser) context is right do they become contextual keywords.

My suggestion: Remove "In addition" in [lex.name] p3, add "(including macro names)" in p3, and switch the order of p2 and p3.

It's a bit unfortunate that "identifier from preprocessing-token" is converted to "one of identifier, keyword, literal, operator, ...", using the same "identifier" string for both levels. Maybe we should have a pp-identifier in the long run.

A pp-identifier would be a good solution, but it's not something we can reasonably do editorially. I'm closing this, but feel free to request a core issue if you still want changes here.