I think that the 'Kind request: fix your packages' thread is going off course by discussing how to fix what we have instead of what we need to implement to make Sean's vision possible while making it possible to support older systems easily.
I think that we need development tools that work more like the tools on Mac OS classic. Macs didn't actually have libraries so they got some very cool features for free. You can actually build an application on Mac OS 9 and run it on Mac OS 1. You don't need a chroot environment or any other fancy setup. All you need to do is stick to the API that Mac OS 1.0 supported and it just works. The bad part was that if you used a function that wasn't supported the application would crash at runtime. Because Linux has library versioning it should be able to get the flexibility of compiling easily for older systems while knowing for sure that the binary will work on the old systems.
On Linux the dependencies of a library or binary get inflated by the system. For example all binaries built on Redhat 9 depend on libc 2.3 but they usually don't depend on any new APIs introduced in 2.3. If each developer compiled against the minimal library versions necessary then the resulting binaries would be nearly universal when used with an rpm repository. For example it would be possible to compile abiword 2.0 with gnome support on RedHat 9 or Fedora 1.0 and have the same binary run on redhat 7.3. The package manager would automatically the gnome2 platform libraries from the Fedora 1.0 release and install them. Although it would require more disk space, end users would probably prefer to have only one Linux/i386 binary just like there is only one Windows binary.
I am not a compiler guru, so I don't know how we get there. It might be a good idea to compile the core of the OS inside a LSB chroot. Another possibility might be using pkg-config to request a specific minor version of a library. It might look something like gcc -o foo foo.c `pkg-config --cflags --libs gtk+-2.0:2.0 libgnome-2.0:2.0 libc-2:2.2`
The library would implement this by specifying a preprocessor macro to set with the requested library version number. Then it would add ifdefs to the headers so that only the symbols available in the particular version would be available. It would be cool to support aliases for different versions. For example gtk+-2.0:LSB_2_0 might be equivalent to gtk+-2.0:2.0.
There might be some extra linker magic necessary, but since RedHat employs lots of compiler tool chain experts I don't think it would be impossible. It might be possible to reuse whatever tools the LSB project is using to generate stub libraries for each minor version of every library.
To make the automatic dependency fetching work right the repository should probably provide a mapping between library names and package names. I would think that it would be easy to write a script that would extract this information from all the rpms in a yum or apt-get repository and write it to a file with a standardized name and location.
In this setup a few programs that can optionally use a feature that a newer distribution has would need to be compiled more than once. Packagers wouldn't need to figure out the dependency information because the developer would have already done that work. Unfortunately, if a single binaries could be built to run on any recent Linux system, then the author of the code would probably package the binary themselves. Some Fedora developers would need to find a new way to spend their free time. ;-)