For P3876R0, I think the overarching point that needs to be answered (and
which was contested last time) is whether we want to support these
additional character types in the first place. There are a few key points
that motivate this:

   1. Historically, we've always signaled encoding using different
   character types, such as using wchar_t-based facilities or u8string in
   <filesystem>. If we concede that it's desirable to have a
   guaranteed-UTF-8 variant of <charconv>, it seems questionable not to
   design it like everything else for the last 25 years.
   2. We don't want to introduce any overhead in the likely scenario that
   the ordinary literal encoding is UTF-8 anyway. In that case, if the user
   holds a std::u8string_view that they want to convert to e.g. a float,
   the implementation could just reinterpret_cast and use the char
   overloads internally. It could even "cheat" and somehow do this
   during constant evaluation, which the user is not able to do.
   3. Say the user wants to implement a function with the signature float
   parse_float(std::u8string_view). Given that there is no upper bound on
   the length of strings (consider 0.000...0001e+10000), the general case
   requires dynamic allocations to implement this function if the user first
   has to transcode into a separate char[]. This is entirely unnecessary
   overhead and raises questions about freestanding support, allocators,
   exception handling, etc.
   4. If we don't provide wrappers around from_chars, users are just going
   to implement such parse_float functions themselves. If you're working
   with std::u8string_view extensively in your code base, having to call
   the char overloads of std::from_chars takes considerable effort.

Considering these points, I don't see any justification not to support
char8_t (and char16_t, char32_t) strings other than if you think Unicode
character types are pointless in the first place and that no one should use
them. Otherwise, it seems inevitable that one would want to parse their
contents sooner or later, and this is not trivial to do if you only have
char support.