I already probably know the answer will be "this is impossible" but hey this surely can't hurt to be asked.

I dev on a codebase that uses variable "space reservations" to basically simulate the capability of having variable sizes of zlevels. For example, if we have a space ship that's 20x20, we really do not want it taking up an entire 255x255 (our base zlevel size) space because that's a huge waste of memory.
The issue is while we can already do this it's
1. Incapable of separation for range()/view()/get turf in range or whatnot without coding custom helpers for it. we don't use >7 range on range/view/etc and "space reservations" are never lower than 15x15 in general for us so this isn't a huge issue but.
2. Checking zlevel needs to be abstracted for things like implementing radio ranges/whatnot
3. Anything like "teleport to random area in range" etc etc is going to need its own custom helpers too.

This is all doable. The issue is that we're basically incuring an order of magnitude more overhead than if this was native to the engine. So we're stuck between wasting space on zlevels (or needing to use a small base zlevel size which has its own issues because we want more playable space on the actual "map" as opposed to individual shuttles/ships), and coding in abstraction for all of this that has overhead and is hard to maintain, making it more or less impossible to use to the scales we require.

So the feature proposal is, how unlikely is it that BYOND will natively have support for better Z management in the near (1-2 years) future?