Just hoping to clarify my own understanding of this, and perhaps making an observation in case this is helpful to others... I know that some of this has been discussed in specific circles.

It is my understanding that this paper introduces a concept of compile-time conversion of strings associated with the `char` type (and also the same for `wchar_t`) into a "format string". I believe this necessitates attaching semantics to the "character" values (at compile time) to recognize characters such as the left brace (`{`). It is observed that the coded value of the left brace character is locale-variant in certain environments. Thus, the paper is establishing that format strings are not parsed based on locale. I am aware that the intent is to specify that the interpretation is based on the encoding used for literals; however, at this time, the wording does not indicate that intent.

I am not aware of implementation experience for this paper in environments where characters significant to the interpretation of the format string are not locale-invariant. There is, however, reason to believe that an implementation can be realistically deployed to such environments while giving some ability of the user to choose the text encoding under which format strings are parsed. As it is, the paper uses format-string and wformat-string as exposition-only types in the signature of the `format` functions. It is possible for an implementation to version these functions (across translation unit boundaries) through embedding the text encoding information into these types. A mechanism such as std::text_encoding::literal().mib() from P1885R5 (which has not yet advanced to plenary) could be used.

The above approach is perhaps more limiting than strictly necessary upon extensions that allow the translation of string literals to be changed within a translation unit. It is noted that P1885R5 exposes the literal encoding as a consteval function, which is compatible with context-sensitive evaluation by the implementation. In case there is an appetite to allow for such context-sensitivity for format strings, it is probably the case that updating the text to allow for exposition-only extra parameters in the signature is purely a specification matter and does not affect implementations where such scenarios do not occur. It is also rather likely that implementations which do employ such extra parameters are conforming anyway (because the extra parameters are only observable when a user applies an extension). Nevertheless, the paper may be just the beginning of a number of changes that are candidates for being considered retroactive to C++20.

TL;DR: The paper sets a direction (but does not actually spell out that it does) of using the encoding associated with literal translation for parsing format strings. The work around improving the management and handling of said encodings is still ongoing; therefore, where this paper leads us is not as clear as it could be given additional time. Nevertheless, it is probably the case that further incremental improvements can be made on top of this paper without compatibility breakage for implementations that choose to deploy earlier. In certain environments, quality-of-implementation around this paper may be dependent on additional improvements to the specification. Since this paper is being considered to be retroactive to C++20, it is reasonable to expect that improvements of the aforementioned kind would also be considered for retroactive inclusion as they are discovered.