The hazards of 32/64-bit compatibility

In order to run 32-bit code, the userspace process has to run in 32-bit compatibility mode at the hardware level -- this is a setting on x86_64 processors to temporarily emulate 32-bit processors. So the kernel needs at least that much support, since I believe entering and exiting compatibility mode is a privileged operation.

You could potentially imagine doing the syscall 32/64 marshalling in user space, but you have the problem that unless you do something really clever and/or scary, that marshalling has to run in 32-bit mode because of the above fact, even though it's trying to talk to 64-bit kernel interfaces. Since the 64-bit kernel interfaces rely on using e.g. the full 64-bit registers, this is probably impossible.

You could perhaps have some new interface that accepts 64-bit data, but in a form accessible to this 32-bit shim layer, but there would almost certainly be a performance cost associated.

There are other problems, too, such as this shim having to know about virtually every ioctl in the kernel, something that would be nigh-impossible to keep up to date.