The initial part seems to always be the same, regardless of base or whether the floating-point number is decimal or binary. That is, forming a mantissa integer from the integer and fraction, and parsing the exponent separately.
Since this initial part is always the same, and the lowest level one can provide before the algorithm-specific parts begin, I think it makes sense to expose it.
I see no point in passing in Ints to represent the digits, that is not going to be efficient. It is just better to pass in a span of individual digits (because that is probably the form that they are going to be in anyway).
This can be done by either having the digits mapped to ASCII (which is form the data will most likely be in anyways) or transcoded to binary digit representation.
It's going to be efficient because that's what dragonbox and fast_float do anyway. The first part is computing the mantissa and exponent, and then the interesting and difficult latter part begins.
Just because you can do something, it doesn't always mean it's a good idea, and in this case it is premature pessimization.
The only reason we do this is because humans can't understand binary. So, we have to transform back and forward to a form that monkeys can read with their eyes, that is the problem space.
The point isn't to optimize, but to provide an interface that abstracts from the hard part of the problem, and is independent of text encoding. Obtaining the mantissa and exponent seems like something that always needs to be done, and with that interface, you can support digit separators too, since the caller is filtering them out.
As I've said before, we should propose multiple levels of convenience on top of that lowest-level function. That function which takes sequences of ASCII digits would still exist, in addition.