I think that in the debate over whether char or char8_t makes sense in
the context of system APIs, it's easy to glance over the large number
of non-system APIs and what their interface should look like.

For example, what encoding should std::to_chars and std::from_chars
operate on? It seems like if they operate on char-based strings, this
can only reasonably be the literal or execution encoding, not
"arbitrarily" UTF-8. This propagates to std::format, std::to_string
and all sorts of other things. I can also picture future additions to
the standard such as a function that tells you whether a string is a
valid C++ identifier. This seems useful for reflections, and does not
go through any kind of system API.

Either all of these system-independent APIs would operate on e.g.
std::u8string_view, or the user would have to pass around
std::string_view + std::text_encoding. The latter option seems totally
backwards to me, and like regressing from a std::span-like design back
to passing a pointer and its size, separately.