Proposed resolution (June, 2014):

1. Change 5.5 [lex.pptoken] paragraph 4 as follows:

[Example: The program fragment 1Ex 0xe+foo is parsed as a preprocessing number token (one that is not a valid floating or integer literal token), even though a parse as the pair of three preprocessing tokens 1 0xe, +, and Ex foo might produce a valid expression (for example, if Ex foo were a macro defined as +1). Similarly, the program fragment 1E1 is parsed as a preprocessing number (one that is a valid floating literal token), whether or not E is a macro name. —end example]

2. Delete 5.13.9 [lex.ext] paragraph 10:

Some identifiers appearing as ud-suffixes are reserved for future standardization (16.4.5.3.6 [usrlit.suffix]). A program containing such a ud-suffix is ill-formed, no diagnostic required.

3. Change 12.6 [over.literal] paragraph 1 as follows:

The string-literal or user-defined-string-literal in a literal-operator-id shall have no encoding-prefix and shall contain no characters other than the implicit terminating '\0'. The ud-suffix of the user-defined-string-literal or the identifier in a literal-operator-id is called a literal suffix identifier. [Note: some Some literal suffix identifiers are reserved for future standardization; see 16.4.5.3.6 [usrlit.suffix]. —end note] A declaration whose literal-operator-id uses such a literal suffix identifier is ill-formed; no diagnostic required.

4. Change 16.4.5.3.6 [usrlit.suffix] paragraph 1 as follows:

Literal suffix identifiers (12.6 [over.literal]) that do not start with an underscore are reserved for future standardization.