From a pragmatic viewpoint of saving some space, it might make sense. But from a design viewpoint it's not really a "minimal necessary feature" to do something

From a pragmatic viewpoint of saving some space, it might make sense. But from a design viewpoint it's not really a "minimal necessary feature" to do something you can't do already, so specifying it as part of the standard just bloats things up for no reason. What I mean by that is, the Wasm GC primitives were designed the way they are to be the smallest possible additions for the best uplift. When other primitives are added like SIMD, it's because they're the "roughly minimum primitives" to achieve those features. You want the smallest possible building blocks, there. But a memory allocator API for malloc/free or whatever is not a minimal feature. A memory allocator is actually a bunch of policy and design decisions, and the algorithms used by the allocator will flow from those. The fundamental building block there is just "a linear piece of memory owned by the allocator", and that already exists. It's the linear memory WASM has had since day 1! It might make sense for individual runtimes to do it though, i.e. give some built-in wasm import a piece of the linear memory and let a runtime-implemented allocator handle it. But it would almost certainly never become standardized I bet, and almost all of the tooling for non-GC'd Wasm languages is basically designed around porting working, existing codebases, including their allocators. So it's just more code to maintain for one-off implementations. The juice might not be worth the squeeze.