Hey Hubert, I sadly missed the last meeting, which I'm guessing provides some necessary context here.
This was more of a concern I raised on the side that was not much discussed in the meeting. I did fail to relay important context though: The ordinary/wide string literal encodings are properties of the compilation environment and there is no guarantee that the runtime environment has the facilities necessary to programmatically decode those encodings (e.g., maybe literals in the program are only passed to fputs).
The leakage of literal encoding information into the type system (at some level or another) was also briefly mentioned. Related unspoken context is that separately-compiled translation units (e.g., third-party library packages) will potentially have different literal encodings. Strategies to contain the ODR-violation fallout should be employed.
I'll try to answer some of these things in a vacuum anyway, i like to live dangerously!
Generally, I'd be rather concerned about the need to reason about literal encoding at runtime.
Without a way to track in the type system whether a string was produced at runtime or at compile time (including those who are produced by constant evaluation),
Treating runtime strings the same way as compile-time strings was (iirc) part of the motivation for specifying interpretation using the literal encoding in the first place. We don't need to differentiate between strings produced at runtime versus compile-time for encoding purposes with the current specification.