The following sentence at https://eel.is/c++draft/lex.phases#1.3 states that it is unspecified whether a sequence of whitespaces other than new-line is replaced by a single whitespace or is maintained as-is:

Whether each nonempty sequence of whitespace characters other than new-line is retained or replaced by one space character is unspecified.

This could be troublesome for scenarios where the integrity of the resulting literal string given by the stringize pre-processor operator is affected if there are multiple whitespaces in play: should these be kept in the resulting literal string or replaced by a single whitespace? Both scenarios would be theoretically fine, because it's unspecified and the implementation could pick any, but it is usually more intuitive to think that it will be maintained as-is, the following example showcases this problematic:

#define foo(x) #x

const char* bar = foo(hello   world);

Denote the 3 whitespaces between hello and world. Here, an implementation could opt to include the 3 whitespaces as-is, "hello world", or replace these by only 1 whitespace, "hello world", while only the former behaviour is intuitive, and the latter could give unexpected results that could lead to erroneous behaviours.

To solve this, i propose the following change on the wording of https://eel.is/c++draft/lex.phases#1.3:

The source file is decomposed into preprocessing tokens ([lex.pptoken]) and sequences
of whitespace characters (including comments). A source file shall not end in a partial
preprocessing token or in a partial comment.9 Each comment is replaced by one space
character. Whitespace characters are retained. As characters from the source file are
consumed to form the next preprocessing token (i.e., not being consumed as part of a
comment or other forms of whitespace), except when matching a c-char-sequence, s
char-sequence, r-char-sequence, h-char-sequence, or q-char-sequence, universal
character-names are recognized and replaced by the designated element of the
translation character set. The process of dividing a source file's characters into
preprocessing tokens is context-dependent.