I re-read your post and wanted to clarify what you meant by:

  Apple (and previously NeXT) inarguably demonstrated its
  value and ease-of-use over the past 20 years. Producing
  x86-32, x86-64, armv6, armv7, and PPC binaries all from the
  same source code -- and having them work the first time --
  is incredibly simple on Mac OS X.

Presumably you aren't under the impression that FatELF has anything to do with making source code easily compile to more targets. FatELF merely allows you to combine the binaries that would result from taking a source code base and compiling a binary for one arch and then another and gluing those together into one file.

The wording on your post wasn't entirely clear, though I'm guessing we're on the same page.

OS X has a unified set of libraries to work with, Linux does not. This means the problem is much more complex. Creating a binary that simply runs on different distributions all on the same architecture is a fundamentally hard problem. Simply stacking together binaries for multiple architectures together doesn't result in a universal binary. At worst you have to stack together different binaries for different combinations of libraries and different architectures and if you assume even just the latest versions only of the top 5 distributions running on the top 5 supported architectures for Linux you may well end up with 25 different binaries that FatELF would glue together resulting in every program being a cool 2500% larger. This is unacceptable in terms of space and unacceptable in that it still isn't universal after all that as not all arches are supported and you only get the latest versions of the popular distros.

This is why I claim FatELF does not solve the hard problems with universal binaries. The only thing it might solve is someone could distribute a binary for a particular distro that could run on multiple architectures for that distro, but they can already do this with shell scripts and this is an uncommon case and most people would just rather download and store the one appropriate binary.

(This last is easy with a functional package management system. You should keep in mind that OS X does not have a functional complete package management scheme that allows users to discover, acquire and manage 3rd party packages. Not all Linux distros do either, but those that do are less in need of universal binaries. This is really a separate discussion though that gets to the heart of how software ought to be distributed. There are many blind spots in OS X's software strategy some of which Sparkle is making a half-baked (not sparkle's fault) attempt to fix.)[1]

At the end of the day you can't simply assume that the solution for OS X is the right one for Linux and you'd make a much bigger mistake assuming that the developers who rejected these patches weren't both entirely aware of OS X's excellent use of this technique and were doing this for anything but sound technical reasons. (I.E. It's not just NIH, they would happily adopt this if this was a reasonable solution to Linux's unique[2] challenges with binary compatibility across "Linux")

[1] There are many things wrong with this and most package management systems do not incorporate third party repos/packages as well as they should, which IMO is the larger problem here. Not that corporations should have to manage repos for every distro, but that becomes a separate mess.

[2] Perhaps read as special.

Aside #432: As you noticed my replies can often be anything but concise. I apologize if that makes things hard to follow.