A big problem is that it requires an entire ABI and operating system support to handle this case, when the alternative is... just use a custom heap in your own

A big problem is that it requires an entire ABI and operating system support to handle this case, when the alternative is... just use a custom heap in your own program. You're describing an insane level of engineering for something that mostly is hidden and can be handled just as effectively by the applications. Like, if you're in the weird case where A) pointer chasing is killing your performance and blowing your cache and B) your working set fits in 4GB, you can just fix this yourself with your own custom allocator to handle that. You'll still be pointer chasing, mind you, just half as much (and there's the thing: you could very well be much better off reducing the chasing you're doing versus mitigating it this way.) In reality superscalar OOO processors hide miss latency very effectively helping mitigate the problems of A, and B isn't always clear from the start. So here we are. Don't get me wrong, I want more efficient programs, and centralizing some complexity like ABI is a good thing. But in practice x32 was a massive technological investment for something that mostly didn't matter, that people mostly didn't need, and whose benefits can be gotten much more easily and directly in a lot of cases.