All the tools were there.
WebAssembly is still not safe from internal memory corruption, due to lack of memory tagging and bounds checking.
Unsafe applications won't ever be magically safe when compiling them to WebAssembly. Neither would this be the case when compiling to Java bytecode - if this was possible at all.
IMHO WebAssembly is a compilation target and therefore not the right layer to solve this. This is the responsibility of the language or the specific application. If you want to solve this in WASM, I predict you couldn't just compile all different languages to WASM anymore without significant changes to the codebases. If this would be feasible at all..
Rewriting those huge C/C++ codebases is simply not an option, new applications can be written in safe languages and then compiled to WASM.
CLR proves the contrary, by having C++ support, with the difference between safe Assemblies (where typical memory corruption opcodes are not allowed, compilation via /CLR) and unsafe Assemblies, where WASM like opcodes are allowed.
To load an unsafe Assembly, the host has to explicitly allow it.
Similar examples on IBM and Unisys language environments, e.g. on ClearPath, the admin must allow the execution of binaries tainted with unsafe code.
PHP is memory safe, and yet is a larger source of data breaches and security bugs than C by (rough guess) an order of magnitude.
C is not the bogeyman you're looking for.
Garbage Collected implementations of C and C++ do exist, and only thing that their GC fixes is use after free.
