WASM as a result isn't changing anything here, since the assembly is very extremely not remotely close to the issue with having a portable binary.
So, now the effort is being rebooted with WASM Components.
Having actually portable APIs and abstractions such that you don't need to be concerned with differences in file paths, system behaviors, system services, audio, video, windowing, input, etc...? Yeah, WASM isn't the answer to that and it's not trying to be either.
The reason Java/.NET "failed" had nothing to do with being driven by only one player and everything to do with the abstractions are so high level at that point as to be problematic. Which you either need to fully embrace, and end up with Electron, or you end up trying to reinvent WxWidgets or AWT and the clunky compromises that result where it's really just easier to build a platform-specific binary
Also both Google and Microsoft have (or currently have) their own Java bytecode runtimes. So that's not even locked up by one player, and just compare Android vs. desktop JVM to see the inevitable future of "portable WASM"
Write once, run anywhere is true with cross compilers and native executables without any bytecode intermediate formats. Or even things like APE executables and cosmopolitan-libc.
The hard part is finding portable libraries to actually do anything interesting. Networking, graphics, GUI, peripherals. WASM is not helping here and maybe even makes things a bit worse by introducing yet another platform to the portability matrix.
I do see the allure of using WASM for sandboxing, plugins and running untrusted code. Things where the distribution part matters.