@foota, WASM GC is a bad development because it's opinionated. For example, the nice WASM <-> CPU bijective mapping of capabilities is going to be lost. WASM G

@foota, WASM GC is a bad development because it's opinionated. For example, the nice WASM <-> CPU bijective mapping of capabilities is going to be lost. WASM GC now turns the WASM into something completely different, something in the rank of Java, .NET, Flash, Node JS, or Elang. For any GC to work, there must be a notion of a component model that defines the type system and the rules of type interactions. This is a complex topic by itself with myriads of decisions and compromises to make. This means that the end result won't suite everyone, if anyone at all. This will lead to WASM GC stagnation - it will be there but nobody will be using it because no one wants to loose the ground and compatibility with real CPUs. There may be some users like Dart or Flutter with their niche opinionated situations, but it's a drop in the ocean. As the time will pass, WASM GC will be gradually becoming a burden as it does not come for free - it requires maintenance, patches, security fixes. In the end, browser vendors may proclaim the WASM a new "Flash", "Java Applet", "ActiveX" that should be eliminated due to overdesigned complexity, too wide API surface, and associated security risks. Rinse and repeat, there is nothing new under the sun.