> Just because I have provided crypto as a possible use case for 128-bit integers doesn't mean that my proposal is about multi-word arithmetic for cryptographic purposes.

So, do you agree that crypto is not a justification then?

> A std::mul_wide function does not mean that you can print 128-bit integers using std::print now.

That's right. You can't. That was never the point.
64-bit was never enough, 128-bit is not enough, 256-bit is not enough, N-bit is not enough. You can always find an application that requires an ever-increasing counts of integer bits as far as computers have enough storage to hold them, and at what point should you stop and say enough is enough?
We have the types that we have because they are efficient, they can be implemented efficiently, they have a set of well-defined properties. Extended width arithmetic allows to use the types that you have, preserving precision and allowing you the implement the types that you don't, they are a cap on top of what you can do to allow you to do more.
Adding an additional n-bit width integer doesn't stop the problem, it just makes it 2x times wider.


> The core language already permits the implementation to provide additional extended integers such as std::int128_t. However, the standard library does not allow an implementation to define std::to_string(std::int128_t) in that event.

I agree with that, if the standard provides std::int128_t, it should allow std::to_string(std::int128_t), and all other numerical manipulation functions.
And I also agree, if there's nothing officially that supports anything beyond "long long" that should be a problem of the compiler, not of the standard.

But that is more of a problem in terms of how these functions have been defined, and how integers in particular have been historically defined.
From a modern perspective the set of "char, short, int, long int, long long int" are terrible (hindsight is 20-20), but right now must be kept so that our infrastructure can keep functioning.
There are ways to solve this, but that is a separate discussion.
But the wording of the functions should be fixable to allow support for whatever integer types are available, if the integers are available (or satisfy a well-defined condition) then you support it, if they are not then you don't.

But that is a separate discussion from, should std::int128_t be mandatory in the first place?