> Seems like it will be useful for use-cases like embedded where you're restricted to certain parts of the library anyway. But the battle is kind of already lost for support at the level of Zig or Odin.

Odin in particular does a simply terrible job here. Take the most common need for allocations, a growable array type, in Rust Vec<T> and in Odin dynamic[T]

In Rust we only pay extra to store the allocator metadata if there is allocator metadata. If we're content using the general purpose allocator Global with global metadata it's free. In Odin we always need to pay to store an "allocator proc" function pointer and a (possibly unused) metadata pointer, so that's 2x machine word worse for Odin. We pay this even if we never allocate, and indeed even if we can't allocate, whereas of course in Rust that's free.

But then when we do need to allocate, in Rust that's a static dispatch unless our allocator specifically wants dynamic dispatch. So again for Global it's just a static dispatch. But in Odin it's always a slower dynamic dispatch.

The upside? To the extent there is one it's probably the New Jersey style, ie it was simpler to implement Odin. Which is a benefit to Ginger Bill, but not to you as an Odin programmer.