Given that big int libraries have existed for a while, why is there a pressing need now?
There is no "pressing need" in terms of timing. It's simply something people have tried to standardize as early as 2004 because it has always been and will always be immensely useful. The paper's motivation section goes into great detail as to why std::big_int should be in the standard.
That is, the largest possible unsigned integer type that has native arithmetic support.
What keeps this from suffering the same problems as intmax_t; i.e., once baked into ABIs it is effectively impossible to change when the underlying hardware does.
"When the underlying hardware does" is a pretty unlikely scenario, and I'm not sure if it has ever happened in the history of computing in a way that would change a std::uint_maxfast_t type. This would require providing new arithmetic instructions with greater width, on an existing architecture, without creating a new ABI. For example, it would happen when providing 128-bit arithmetic support on x86_64. Usually, that doesn't happen, and the historic jumps from 32-bit to 64-bit came with completely new ABIs.
The issue with std::intmax_t has always been much simpler and dumber, up until C23 fixed it. You could not add a new __int128 extended integer type as an implementation without also changing std::intmax_t. std::intmax_t would force you into an ABI break even if nothing about the hardware changed.
I'm thus interested in standardizing a type alias in <stdint.h> that has the size. In P4444, we call that uint_multiprecision_t, but that's perhaps not universal enough. Names like "uint_maxfast_t" or "uint_word_t" come to mind.
I was never really enamoured with the int_fastN_t types, since they don't guarantee, well, anything other than being at least N bits wide. This doesn't seem any different, because "fast" isn't clearly defined.
It is different. The wording we have in
https://isocpp.org/files/papers/D4444R0.html#big%2eint%2esyn recommends it "should be chosen to have the greatest possible width so that an arithmetic expression ([expr.pre]) performed on operands of the type corresponds to a single instruction in the execution environment."
That's a lot more specific than "fast".
That we are re-inventing int, badly. The original intention of int was that it be the "fastest" type on the target, whatever that means.
Yeah well, that original intention was lost 20 years ago or something. I think the idea of int being the native integer type was always destined to fail because it's clunky to leave a hole in the standard integer types, where short is 16-bit and int is 64-bit. Or perhaps, short would be 32-bit, leaving no 16-bit type. It would have also made long and long long basically useless on 64-bit and sparked a 64-bit dialect of C++ where people use int only, avoiding any of these wider types.
On 128-bit architectures like RV128, it would have become even more comical, with short presumably still being 16-bit and int, long, and long long all being 128-bit.
You would inevitably need to patch the holes in the standard integers with extended integer types or add more standard integer types, and neither seems like a desirable outcome.