Proposed resolution (approved by CWG 2025-09-26):

1. Change in 5.13.5 [lex.string] paragraph 1 as follows:

     string-literal:
         encoding-prefixopt " s-char-sequenceopt " plain-string-literal
         encoding-prefixopt R raw-string
   
     plain-string-literal:
         " s-char-sequenceopt " 
   

2. Change in 15.3 [cpp.include] paragraph 7 as follows:

   A preprocessing directive of the form

     # include pp-tokens new-line
   

   (that does not match the previous form) is permitted. The preprocessing tokens after include in the directive are processed just as in normal text (i.e., each identifier currently defined as a macro name is replaced by its replacement list of preprocessing tokens). After replacement, if the first preprocessing token is a string-literal, it shall be a plain-string-literal. Then, an attempt is made to form a header-name preprocessing token (5.6 [lex.header]) from the whitespace and the characters of the spellings of the resulting sequence of preprocessing tokens; the treatment of whitespace is implementation-defined. If the attempt succeeds, the directive with the so-formed header-name is processed as specified for the previous form. Otherwise, the program is ill-formed, no diagnostic required.

Editing note: The second change of the proposed resolution is superseded by the resolution of issue 3078.

(From submission #768.)

Consider:

  #include L"hello"

When forming a header-name preprocessing token from pp-tokens in 15.3 [cpp.include] paragraph 7 is bound to fail when the first such token is a string-literal with an encoding-prefix or R. Such a failure is specified to be ill-formed, no diagnostic required, but implementations uniformly diagnose the situation.