I am not sure if we want to hook such a low level function unless we have no other choice.
E.g. for Vulkan maps the goal we have is something along the lines of https://github.com/KhronosGroup/Vulkan-Docs/pull/1906 . It would also be nice to handle this more flexibly than mapping everything < 4GB. A lot of allocations are never passed to the Windows application and many libraries that we use allow us to allocate memory first and then pass it to the library, instead of having the library return us some pointer.
MacOS allows us to create a second mapping for arbitrary memory. That's what CrossOver is using for glMapBuffer and friends. In hangover, I blocked every memory above 4GB (by blocking everything below 4GB, then calling mmap until it fails, and then releasing my < 4GB addresses again). Both of these options work but have their own problems.
MAP_32BIT puts the mapping below 2GB, not 4GB. We need the alternative codepath for e.g. arm64 hosts anyway, so I don't think we should bother about MAP_32BIT.