I'm a Unix person, so the notion of long being less than word-length seems pretty silly to me, but I understand why they did it, sort of.
It's silly for Windows to do something a certain way just because that's not how Unix does it?
What's silly is assuming that long and unsigned long are more than 32 bits wide, since neither C nor C++ has ever guaranteed anything more.
What are the advantages of having data types that behave differently on different platforms, like C does? It seems to make code less portable and I'm having difficulty seeing what the benefits are.
I can appreciate that, on an 8-bit processor, you'd want access to an 8-bit data type for speed - but wouldn't that be better accomplished by explicitly choosing an 8 bit data type?
The practical decision to leave the sizes undefined was made so that nobody was burdened unfairly. It's choices like this - not biasing stakeholders toward forgoing a standard for clear business reasons - that makes the adoption of standards likely. Subsequent C standards have adopted the same undefined behavior for the same reasons [there are still 8 and 16 bit systems developed with C] and to facilitate backward compatibility of the new standards.
There are some other types (i.e int32_t, int64_t, etc) that you could use if you want to be sure that your variable would have the same size regardless of the architecture.
Than what? Than a freshly designed C-like language? Yes. But ISO C wasn't an effort to invent a new language. It was an effort to standardize existing practice, and provide a platform for improving C. One of the core goals of ISO C is to maintain every last bit of backward compatibility possible, which is why integer widths are not precisely specified: had they been, multiple vendors' implementations and the code that was written for them would have broken.
But to your main point, I agree: explicitly sized integer types are almost always what you should use. For example, don't store a pointer in an unsigned long (and certainly not a signed long); store it in a uintptr_t, or hell, just store it as a pointer. In fact, the fundamental types like int, long, etc. are effectively just shorthand for int_fast16_t, int_fast32_t, etc., but without the mnemonic value.
In your link they have examples where size_t and ptrdiff_t are 16 bits. Obviously this is absurd on today's machines. But you can imagine a machine where array subscript is most convenient at 16 bits and total addressable space is larger (16 bit x86 comes to mind). By the same token I don't think it would be too weird to have a 32 bit size_t on a 64 bit architecture. It would just make memcpy et al more annoying when your allocations are large.
Anyway the quotation from your link:
> The types used for size_t and ptrdiff_t should not have an integer conversion rank greater than that of signed long int unless the implementation supports objects large enough to make this necessary.
I guess if longs are 32bit and you can have a 4g allocation this pretty well follows the spirit here.