> IMO, fixed-width multiple precision support for any reasonable bit width ought to be provided automatically

That sounds like _BitInt.
https://eisenwave.github.io/cpp-proposals/int-least128.html#bit-precise-integers
explains why I didn't choose to propose it this way. In short, it's a
massive language change and doesn't even get you 128-bit integers in
the form you want.

> The proposal might be better refined by being a bit more specific with something along the lines of "int_fast128_t".

It's unclear to me what the difference between that hypothetical
approach and my proposal is. Mandatory int_least128_t gets you
int128_t on the architectures we care about, and that's ultimately
what matters. This *is* the fast 128-bit integer type.

> That way, if there isn't a "fast" version that fits in a register (or has a corresponding subset of instructions), a warning would be emitted.

A warning saying what? "You're using int_fast128_t but it's not
fast!"? How would this be worded, and is this even in the scope of the
standard? Quality-of-implementation diagnostics generally aren't.

> That said, I haven't seen an implementation that provides the "least" or "fast" variations as anything but aliases.

They are required to be aliases in the C++ standard. How else would
you provide them?