simd128 fills a common need(most games using vector operations) and was a viable option with _broad hardware support_, yes, it adds a ton of instructions and impacts a ton of places with regards to memory ops but vec4 operations commonly use much of those instructions. Better useful than something that will never have a chance of standardization.
On the other spectrum, things like custom-page-sizes seems like a simple flexible solution but smells like an implementation nightmare if you already have a runtime since that really impacts things on a far deeper level (64k pages was probably a mistake, but reading up on the issues of emulating x86 with 4k vs 16k pages on Mac's kinda hints at how devious "small" things like that is), i'm not surprised if it never comes about as an offical part (only 3 runtimes supporting it so far).
I can understand the need for tail-calls but at the same time it's also an annoying can of worms to implement into compilers that wasn't prepared (could have been a large part of why it took so long for Safari to support).
wasm-gc really hit a real-world need (bindings did really suck.. they're better but not perfect now) but also comes in a bit half-assed in some respects (languages like C# needing workarounds to use it), same with memory64 being a real-world need.
I can see different camps (popular/functional languages for gc,m-val and tail-calls), games (simd128, multithreading, memory64), embedded(flexible pages),etc all competing and having focus on what they want but all camps also need to understand that pushing _everything_ will be pushing the risks of the web (security) and in the end that's what wasm was for, providing a runtime to run non-JS code on the web.
My view on specifications is that their long-term success depends on the value they provide relative to their complexity. Complexity inevitably grows over time, so spending that complexity budget carefully is crucial, especially since a specification is only useful if it remains implementable by a broad set of engines.
WebAssembly MVP is a good example: it offered limited initial value but was exceptionally simple. Overall, I am happy with how the spec evolved with the exceptions of 128-bit simd and relaxed-simd.
The main issue I see with 128-bit simd is that it was always clear it would not be the final vector extension. Modern hardware already widely supports 256-bit vector widths, with 512-bit becoming more common. Thus, 128-bit simd increasingly delivers only a fraction of native performance rather than the often-cited "near-native" performance. A flexible-vectors design (similar to ARM SVE or the RISC-V vector extension) could have provided a single, future-proof SIMD model and preserved "near-native" performance for much longer.
From a long-term perspective, this feels like a trade-off of short-term value for a large portion of the spec's complexity budget. Though, I may be underestimating the real challenges for JIT implementers, and I am likely biased being the author of a Wasm interpreter where flexible-vectors would be far more beneficial than 128-bit simd.
Why you think flexible-vectors might never have a realistic path to standardization?
I view it a bit more from the lens of it's initial evolution (Asm.JS) being a wall-breaker to force Safari,etc to keep up. It was done by adding a MVP that was easy to add for all parties (Asm.JS already ran on top of WebGL buffers and JS.. it was mostly a matter of standardizing a way to optimize this in a less hacky way).
In the same way, simd128 was a low hanging fruit with more or less _universal_ hardware support (being a good MVP to bring benefits, more or less fulfilling 99% of what games and other 2d/3d applications need.. important point).
Now as for being future-proof, even today only simd256 would be usable on desktop (so we're only losing half the _potential_ performance) due to how spotty Intel's AVX512 support has been (crashy, P/E core differences, etc), the full potential bought by flexibility in SVE or RV's VE being a thing to look for in the future.
Now, if webassembly had an neural-net or other AI/large-vector heavy focus I'd agree that the omission of a future-proof option is bad, but they've decided to focus on what can be used today and standardize on that since we will actually benefit from that for the forseeable future.
Vector lengths really has been stagnant compared to core counts for hardware makers since it's been more "bang for the buck", the AI focus might still shift that back (even if NPU's has taken the front-seat) but I wouldn't hold my breath for flexible vectors until Intel or AMD jumps on the bandwagon (or ARM and RV chips with really wide vectors takes enough marketshare that it becomes untenable to not support it).
simd128 fills a common need(most games using vector operations) and was a viable option with _broad hardware support_, yes, it adds a ton of instructions and impacts a ton of places with regards to memory ops but vec4 operations commonly use much of those instructions. Better useful than something that will never have a chance of standardization.
On the other spectrum, things like custom-page-sizes seems like a simple flexible solution but smells like an implementation nightmare if you already have a runtime since that really impacts things on a far deeper level (64k pages was probably a mistake, but reading up on the issues of emulating x86 with 4k vs 16k pages on Mac's kinda hints at how devious "small" things like that is), i'm not surprised if it never comes about as an offical part (only 3 runtimes supporting it so far).
I can understand the need for tail-calls but at the same time it's also an annoying can of worms to implement into compilers that wasn't prepared (could have been a large part of why it took so long for Safari to support).
wasm-gc really hit a real-world need (bindings did really suck.. they're better but not perfect now) but also comes in a bit half-assed in some respects (languages like C# needing workarounds to use it), same with memory64 being a real-world need.
I can see different camps (popular/functional languages for gc,m-val and tail-calls), games (simd128, multithreading, memory64), embedded(flexible pages),etc all competing and having focus on what they want but all camps also need to understand that pushing _everything_ will be pushing the risks of the web (security) and in the end that's what wasm was for, providing a runtime to run non-JS code on the web.