OK, so what you want is to create a generic parsing framework that
doesn't really do much on its own, but can be used to *build* number
parsers that could handle arbitrary formats of numbers. That's
interesting.
You're making it out way more complicated than it actually is. std::from_chars works with "1.0", and we may as well pass "1" and "0" separately so that we're not restricted to using a dot as a separator. The use case can be as simple as getting numbers that use a comma instead, perhaps because you're making software localized for Germany. It doesn't take a whole framework to want a slightly different number format.
But why does this need to be in the *standard*?
Because the job of the standard library is to provide low-level, hard-to-implement functionality that others can build software on. Only letting you parse a very-specific floating-point format leaves room for a lower-level function, and that lower-level function exists in all standard libraries anyway so that std::from_chars can be implemented. Don't believe me? The first thing that libstdc++ does is a bunch of parsing to split up the string, obtain the mantissa, etc.:
https://github.com/gcc-mirror/gcc/blob/4c40e3d7b9152f40e5a3d35060b6822ddc743624/libstdc%2B%2B-v3/src/c%2B%2B17/fast_float/fast_float.h#L2974 This is the easy part that the user could have done themselves. The hard part is the load of numerics to turn that into a floating-point number.
If your standard library leaves room for lower-level functions for no good reason, the design is bad. Sometimes there are good reasons, like the standard library needing to be platform-independent, and an OS-specific function exposes more functionality than the standard. However, this is not such a case.
Also remember that std::from_chars exists precisely because std::istream, std::stof and etc. all left room for a lower-level function. std::from_chars just settled for a half measure.
The primary compelling motivation for `to/from_char`s is this: there
is a lingua-franca number format, a de-facto standard for numeric
interchange between programs. This standard is supported by most
textual interchange formats: JSON, YAML, CSV (to the extent that this
can be considered a format), etc. Almost all of these formats use the
lingua-franca encoding for textual interchange (UTF-8), and they all
basically agree on how numbers should be formatted. Lots of programs
generate such numbers, and lots of programs have to read such numbers.
Because of the substantial widespread use of textual numbers in such
formats, there is an obvious benefit to having a tool that can rapidly
handle numbers in those formats.
Once you start talking about an omni-number parser, one which is
basically a set of parsing tools that you compose to parse any format,
the justification for standardization becomes a lot less clear cut.
Such a tool can be very useful for particular users. But the question
of why it needs to be in the C++ standard? Is it useful enough to be
worth adding, or can people just use the library?
It seems like you're contradicting what you've previously said. I am not proposing an "omni-parser"; I am proposing slightly lower-level access to floating-point parsing than std::from_chars, and that functionality already exists.
Arguing that "1.0E3" should be the only format parsable by the C++ standard library is just as nonsensical as arguing that std::from_chars for integers should only accept "0xff" as a format for hex integers, rather than taking a digit sequence and an int base. I could go through a list of places where the "0x" format is used, just like you've done with JSON and YAML, but it wouldn't make the argument any better.