My favourite use for this feature is via `qemu-user-static`, which allows you to transparently "run" executables compiled for other architectures thanks to QEMU emulation. Very handy for embedded systems development.
For one thing, lack of demand. Linux distributions can relatively easily ship different packages for different architectures, and doing so is more space-efficient. It seems to me like shipping multiple binaries within a package is mostly useful for the distribution of proprietary software, and even in that case, it isn't that hard to ship two binaries and a shell script.
That's a function of your runtime dynamic linker, which is most likely provided by glibc (on linux). I believe it supports a.out still; at the very least, it used to.
Nope. It's a function of the kernel, which needs to know the binary format in order to load the executable. The dynamic linker is invoked at a later phase of execution, and in the case of the ELF file it does that by reading the dynamic linker's name from the PT_INTERP entry in the Dynamic table stored in the PT_DYNAMIC segment. By default, if the kernel doesn't recognize the ELF magic (first 4 bytes in the file are `\0x7fELF`), or can't load the dynamic linker specified in the PT_INTERP entry (eg. wrong architecture), it will launch /bin/sh as the interpreter and feed the loaded file to it assuming it's a text file containing a shell script.
If the kernel has the bin_fmt mod loaded, it can also recognize other binary formats before falling back to /bin/sh.
It seems like you’re really asking two questions. My comment for the first one is that you can use binfmt_misc to add your own executable formats. For the second one, is there anything other than Mach-O that does that?
My favourite use for this feature is via `qemu-user-static`, which allows you to transparently "run" executables compiled for other architectures thanks to QEMU emulation. Very handy for embedded systems development.