The link to the library is 404.

The way I see it, this proposal stands or falls with necessity. Your
Prior Art section talks about how much faster it is to have these
functions compared to using to_chars to determine the size, but it
doesn't talk about whether this strategy makes sense in the first
place.

You can over-allocate, as you've said in Motivation. Is
over-allocating so costly that this approach becomes preferable? What
is the use case here, really? What about over-allocating, performing
all the conversions without checking for size, then re-allocating? If
to_chars_size is half the cost of to_chars for floating-point,
couldn't this be cheaper? After all, copying some memory shouldn't be
that costly. This needs some benchmarks and deeper discussion.

Also note that your to_chars_size function for integers is
mathematically floor(log(value, base)) + 1, except for the case of
zero. Floating-point to-chars_size is pretty expensive anyway, and an
integer logarithm function (taking bases beyond int) would solve the
case of integers while being more generally applicable. These design
trade-offs need to be discussed.