> Are you saying that such a library implementation (even on a sane platform) would not be conforming to your proposal?

No, the code you have shown would be valid. After the discussion in
here, I have added the restriction that int_leastN_t must not be a
standard integer type for N > 64.

Other than that, the vendor can just do what they please. It might not
be a good idea to use _BitInt(128) as a 128-bit type in the long run
though, since it needs to have the same conversion, promotion, and
overload resolution rules as standard integer types.

This should also be the case if _BitInt(N) actually became a standard
feature and therefore, std::int_least128_t had to play nicely with
_BitInt(1000).

> .. in order that they arrive at the same place and can be made synonymous. Ditto the sure-to-be-proposed-in-the-future

It's not obvious that this would be a good idea. In practice, any
standard library defines the <cstdint> aliases to be standard integer
types, and their semantics are untouchable without breaking billions
of lines of code.

I think of the <cstdint> system as a legacy type system that would be
entirely replaced by _BitInt in the long run (given a few decades),
not as something that would integrate them.

> I don't want to have two subtly different hierarchies of integer types with the same object representations but subtly different behaviors!

Unfortunately that's exactly what _BitInt is and does, for better or
for worse. Bit-precise integers are an entirely different category of
integers in C, with different conversion and promotion rules. It's not
pretty that we have these two separate type hierarchies now, but
that's neither a problem my proposal is introducing, nor something
that can really be changed. The train to have a nice type system has
left the station in 1980.