Proposed resolution (approved by CWG 2026-04-17):

Change in 5.5 [lex.pptoken] bullet 5.4 as follows:

• ...
• Otherwise, the next preprocessing token is the longest sequence of characters that could constitute a preprocessing token, even if that would cause further lexical analysis to fail, except that
  • a string-literal token is never formed when a header-name token can be formed, and
  • a header-name (5.6 [lex.header]) is only formed
    • immediately after the include, or embed, or import preprocessing token in a #include (15.3 [cpp.include]), or #embed (15.4 [cpp.embed]), or import (15.6 [cpp.import]) directive, respectively, or
    • immediately after an import preprocessing token that is at the start of a logical source line, or
    • immediately after a preprocessing token sequence of __has_include or __has_embed immediately followed by ( in a #if, #elif, or #embed directive (15.2 [cpp.cond], 15.4 [cpp.embed]).
    A preprocessing token is considered to be immediately after another preprocessing token if the preprocessing tokens are on the same logical source line and there are no intervening preprocessing tokens.

(From submission #881.)

The rules inn 5.5 [lex.pptoken] bullet 5.4.2.1 and 15.1 [cpp.pre] bullet 2.2 form a circular definition when specifying the formation of a header-name preprocessing token.