Yeah, we could likely have more languages with size-guaranteed types now, but that's because 32 bits and 64 bits are honestly big enough to do most integer-y type things with. Even the smallest, a signed 32-bit integer, is still good for over two billion numbers before you have to deal with wraparound, and unsigned 64-bit ints are bigger than most applications will ever truly need.

However, freezing on a 16-bit integral type would have been massively annoying. Even unsigned 16-bit values are simply too small to give unique numbers to really large numbers of things; look up why the Unix time(2) syscall takes a pointer as its argument, instead of just returning an integral value. Freeze on a type that small, and you get work-arounds which are more failure-prone than what you're trying to prevent.

And if you go back far enough, you'll get to times when freezing on 18-bit and 36-bit sizes might have seemed like a good plan...

My assumption is that someday we'll add things like int128 and so on. The important idea is that the size of any particular type is fixed for all time when it's created and is guaranteed to never change later. We can always add more types over time, just as we have so far.

(As a practical example, Go has a full set of signed and unsigned integer types in 8, 16, 32, and 64 bits, all specified as being exactly that size. If you write code using uint16, you know exactly what you're getting regardless of what Go does in the future. It's possible that someday your uint16 code will have unfortunate performance implications, but that's another problem; the compiler and language specification guarantee that it still works.)

Freezing odd sized types is a potential problem. My current view is that that's what deprecating language features is for in the long run (and even before then the code is likely to perform increasingly badly because things have to be emulated, which encourages updating it).

People started chanting "Not all the world's a VAX" practically the day the first VAX went into production.

I continued fixing 64-bit bugs in code that had already been ported to DEC Alpha and SPARC64 platforms back in 2005 or earlier, and of course I went on to port even more code to such platforms back then as well.

It's very sad to see a paper written newly this year documenting continuing problems with such code migration, but even more sad is that it is not unexpected to see such a recent paper on this topic.