Matthew Paul Thomas the solution to this lays all the way back to when Sun Microsystems Designed ELF.  This exact problem was considered.  Most Linux distributions have failed to use Elf properly so causing this problem.

Linux ld.so most distributions use is called ld-linux.so.   People forget why.  On solaris is is called ld-solaris.so and so on.

This allows different applications from different OS systems using elf to have different libraries spat up.  Different loader different configuration directory.  With Unix systems this is not much of a problem there is min number of releases using the same loader.  Linux o boy.    We have how many different distributions using the same loader.  Are we nuts???  Why is it are we nuts.  Because if someone force installs a binary not compadible its going to run and it could cause big problems.

ld-linux used by everyone is a bad idea.  Should not have be done.  Since now this means we must depend on package manager to keep applications from different time frame from fighting with each other.   This leads to dependancy hell were we need a old application because it works with our data and a new application to access something else due to them sharing the same library they cannot be installed at the same time because teh package manager has to refuse because there is only one loader.

Now where is the problem coming from.  Linux we have different distrobutions branches and everything is using the same loader so at the active load path there is nothing telling them appart.

Is it possible to change the loader on a prebuilt binary.  Yes it is  https://github.com/NixOS/patchelf/blob/master/patchelf.1 so dpkg itself could alter the binaries loader.  Yes a smarter debsums has to be made allowing for loader change. 

If each release uses a different loader you then can use what is designed for multi arch for storing arch differnet libraries except add a release name to it as well as arch.  Does anything forbid the dynamic loader being told to try its release then all other releases in a order from newest to oldest to find a missing library in fact no.  This allows dependancy hell to be solved since dependancy is now only a distribution branch issue not global once you have a loader per branch.

This is a case of doing stuff against how ELF is designed so its coming back and biting us over and over again. 

The interesting effect of distributions using there own loaders or having package manager change loader on binary is the possiblity of Ubuntu binaries running on Fedora and vice veser using as much of the system libraries as compadible.  Since Alien Distribution Loader would be able to point to a directory containing its own libraries then fail over to system.

Most of the required design alterations has been done for multi arch support.   It is really just a small step forward to multi distribution support.  Arch you can tell what it owns to by the arch id in the elf binary.  Distribution branch needs to be declaed by loader after that the two problems are very much the same.

Yes with multi arch with emulation using native binary code instead of arch code that is not native can be benificial to emulation speed(less emulated).  So yes loaders loading accross the multi arch tree of options has its place.

This could also be used to solve cases like amazonmp3 downloader that is build for a really old version of boost that current ubuntu does not ship.

Really why backport.  Only reason you are backporting in most cases is due to the dependancy hell.  If effort does not have to be put into backporting more effort can be put into QA of the front edge.   Backporting also risks bring back incompadible lbraries so causing more time in QA.

Yes this dependancy hell issue is eating up resources for Ubuntu developerment without any logical reason.

Does this bring any issues.  Yes application installed for testing that now has moved to stable will have to be either reinstalled or loader changed.  Library that has moved from testing to stable most likely will have to be reinstalled.  No more auto migration between the trees.

Nothing is free.  The price I call very minor for the means to run every Ubuntu application ever made.  With the possiblity of running every application from every distrobution.   Yes there is nothing stoping in elf design a ld-linux-ubuntu-<version>.so next to a ld-linux-debian-<version>.so.  This would reduce having to rebuild as many applications.  Ubuntu users could have most of the Ubuntu and Debian repos open to them.  Of course other repos could be brought in the same way.