From what viewpoint do you view them?
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.
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.