1: Letting your code break on pointer size changes is a quite bad sign imho (it's a sign that many other things are probably done with aliasing,etc and has a high risk of breaking due to undefined behaviour once gcc/clang gets around to utilizing it for an optimization).

2: iirc WASM was initially designed to be shimmable via Asm.JS to force laggards(Apple, Google) to implement it, Asm.JS in turn relied on specific rules in JS to get reliable 32bit arithmetic (but impossible for 64bit).

Wasm64 is implemented and works in Chrome and Firefox.. Apple is lagging again with Safari.

I believe 32-bit was chosen partially due to implementation efficiency reasons. It makes sense because you can allocate a 4GB mapping, so there is no need for a second software virtual memory layer. Also perhaps they internally require tagged pointers, which are much cheaper, especially if aligned, if the pointer is only 32 bits

64 bit was added in WebAssembly 2.0 (finished in 2022 according to Wikipedia). I know what doesn't answer any it wasn't there in the first place.

32 is better for a lot of things like simd. the strength of it is wasm can do both types now and js can't unfortunately. a number in js is strictly 64.

Because a web page shouldn’t use 4 GB of ram, and the win is that each pointer can be half the size (better for memory and cache).

The real mistake is requiring pointer to be 64 bit when most programs don’t use it.