"the external interface and requirements are kept simple."
I would bet strongly against that happening long term. Everybody developing WebAssembly is interested in making the web better and pretty much only that. One of the biggest issues preventing WebAssembly usage right now is that you have to ship a large run-time along with your app. So there's going to be a lot of pressure to move that run-time into the browser. See the linked article: GC is the proposal the author highlights the strongest.
The biggest pressure in your favour is the disparity of languages supported. They'll probably want to ensure that any built-in library functions they add are useful to a wide range of WebAssembly communities.
The moment GC is added to WebAssembly will the the moment WedAssembly becomes no more secure than JavaScript. Either that or performance will tank.
The GC is one of the most complicated parts of the browser engine, and serious bugs and exploits are regularly discovered in all of them. Safer languages like Rust won't help at all in the case of WebAssembly because it's not sharing the same type system.
Further more, it's all kind of pointless. No two GCs are the same. A GC is more than simply tracing. Different languages provide different semantics with regards to finalizers, for example.[1] The semantics of the GC closely mirror design decisions of the language. If you're using the JavaScript GC then your language will be limited to the semantics of JavaScript, in which case why are you bothering with some random language?
[1] Are finalizers even supported? Can they run arbitrary code? Can they resurrect the object? If they can, will they run again? Can they throw an error? What happens if they throw an error? In a language like Lua these rules are very specific because they're important to the semantics of the C API, especially wrt to bindings. For example, within a collection cycle Lua finalizers are guaranteed to be run in reverse order of construction.
> Everybody developing WebAssembly is interested in making the web better and pretty much only that.
This is demonstrably untrue. Please peruse the design repo, I think you'll find that there are very frequently discussions of non-web applications, something folks are actually quite keen to support.
Perhaps, but the real stakeholders are the browsers. Do you really think they'd hold off on GC if somebody told them that would make it problematic on embedded?
The same people who work on the browsers are the same people who are in favor of this. The initial authors of wasm created the spec in this way for a reason; it's something they care about.
I would bet strongly against that happening long term. Everybody developing WebAssembly is interested in making the web better and pretty much only that. One of the biggest issues preventing WebAssembly usage right now is that you have to ship a large run-time along with your app. So there's going to be a lot of pressure to move that run-time into the browser. See the linked article: GC is the proposal the author highlights the strongest.
The biggest pressure in your favour is the disparity of languages supported. They'll probably want to ensure that any built-in library functions they add are useful to a wide range of WebAssembly communities.