The addition of a table of contents and numbered sections would make it
easier to discuss and provide feedback on the paper.

In the "Non-encodable character-literals" section:

  * Please add a brief description of what non-encodable characters are.
    Be sure to mention both the translation character set and the
    dependency on the choice of literal encoding. Provide an example.
  * "We believe an implementation should not be able to alter that
    meaning". This seems out of context here; the paper has not yet
    explained the problem it purports to address. Explain why
    substitution characters are a source of problems.

In the "Impact on the standard and implementations" section:

  * For the uninitiated, the fact that Clang uses UTF-8 doesn't mean
    anything here. The intended point is that the problem of
    non-encodable characters doesn't happen when the literal encoding is
    UTF-8. Please say that.
  * There is no example provided for gcc; just the diagnostic. How would
    a reader of the paper reproduce that diagnostic? Does gcc emit an
    error or warning by default? Yes, the Compiler Explorer link is
    present, but that comes later, so this makes for confusing presentation.
  * The MSVC example depends on the choice of literal encoding; no
    warning would be emitted when targeting UTF-8.
  * The MSVC example is confusing; what is ' ?? ?? ', 00H? Are those
    spaces? How do the '?' characters map back to the string? This needs
    more explanation of what is happening (so that you can then explain
    why it is bad).

In the "Are we removing a capability?" section:

  * The section title is confusing. The paper hasn't clearly articulated
    at this point what the proposal is.
  * "exact nature" => "choice"
  * I don't believe the following is true (or if it is, it needs some
    explanation): "in general the relying on non-encodable characters to
    detect the literal encoding is
    non-portable as it can only work on windows". (I don't think I've
    seen code that uses non-encodable characters to try to detect the
    literal encoding; I have seen code that checks what integer value a
    character is mapped to).
  * "? can be inserted in string and character literals". What does have
    to do with this section? Don't leave your readers wondering how
    something relates; draw the picture for them. In this case, I would
    just drop this bullet; no one intentionally uses non-encodable
    characters to write "?".
  * "u8 strings can be used portably". Sure, why is that relevant?
  * "If the author of the code does not care about the content of a
    string being preserved, then presumably that character can be
    removed". This is projecting an intent that the code author probably
    would not agree with.

In the "Multi character literals" section:

  * "However, ’é’ (e, ACUTE ACCENT) or ’ ’ (grapheme cluster), read as
    single characters". The use of "read" here is confusing. I suggest,
    "However, ’é’ (e, ACUTE ACCENT) or ’ ’ (grapheme cluster), visually
    present as single characters, but might not be represented with a
    single code unit (char)".
  * "dificile"
  * "fcould"
  * "into an int. in any sensible way"

In the "Impact on the standard and implementations" section:

  * I don't know what is meant by "Unicode" in "No compiler emit a
    warning for Unicode in multi-character literals".

In the "Feature macro" section:

  * "because the transformation to characters literals and string
    literals is not observable by the program". I agree that there is no
    need for a feature test macro, but not for this reason. From my
    perspective, the lack of a feature test macro is motivated by the
    proposal making some currently well-formed code ill-formed and the
    lack of introduction of any new syntax.

Wording for Character Literals:

  * The struck note needs to be retained for multicharacter literals.

I find the presentation in this paper confusing. In general, I suggest
writing your papers with the following outline in order to guide the
reader through the problem and ultimately to the proposed solution;
maintain a clear separation of concerns between sections.

 1. Abstract
 2. Problem
 3. Motivation
 4. Option(s)/Solution(s)
 5. Proposal
 6. Impact
 7. Wording

Tom.