Do you have evidence that this extra parsing time is a significant
problem that your solution would resolve?

I haven't collected the data on this yet, but in any case, it's ultimately not what makes or breaks the idea. You seem to have misunderstood the idea as being entirely motivated by performance, which it isn't.

The issue with the std::from_chars interface is first and foremost that it's inconvenient to build higher-level parsing functions on top of std::from_chars. For example, Fortran has floats in the format "1.23D+3" and Ada uses the "16#" prefix for hexadecimal numbers. Wolfram Alpha accepts a "_16" base suffix. It's also possible that we obtain the integer and exponent separately from two GUI fields. If we wanted to process numbers in these formats, we would have to concatenate them back into a buffer and convert them into the format that std::from_chars accepts. This isn't entirely trivial; we either allocate by using std::string, or have to pick a buffer size large enough for integer, fraction, and exponent, and it's not obvious what that buffer size is.

The first thing that std::from_chars does is split the buffer back into integer, fraction, and exponent. It is utterly idiotic that we have to concatenate these parts to use std::from_chars, just so that they're immediately split back up.

And it's still utterly idiotic even if the performance impact is relatively low.