LD is documented over several man pages. The 'environment' section of http://linux.die.net/man/8/ld-linux might contain the information you so desperately want to not exist.
Want a --->real world <--- example? UT2004 ships with its own libstdc++.so.5, openal.so, libSDL-1.2.so.0 binaries. It's self contained within it's own directory tree. It doesn't drop files in any binaries into any system system directory. It's worked just fine despite the fact that I've changed distributions gone through many many system upgrades, and etc. over the years. I just copied the ut2004 directory from one system to another and ran it. Worked fine many years ago, still works fine today (completely unmodified) despite the "drastic" changes in distributions I've gone through.
If you look at the ut2004 launcher script that comes with it you'll see the following lines:
LD_LIBRARY_PATH=.:${UT2004_DATA_PATH}:${LD_LIBRARY_PATH}
export LD_LIBRARY_PATH
Check the current dir, check some UT2004 dir, then check whatever the distribution has set up. It's been in the "just works" category for a long time now.
They could have packaged it in .deb, .rpm, .pkg.tar.xz, or what ever package manager you fancy and still be self contained without the need for a new package format.
And even with system libraries we don't have nearly the "dll hell" that we've seen on Windows. The msvcrt.dll vs msvcrt.dll hardly exists on Linux. Unlike Windows where the ABI changes between msvcrt.dll and msvcrt.dll when the ABI changes on Linux so does the file name. It's some.so.1 vs some.so.2. Failing that you can do the same thing application developers on Windows do: ship with your own library version.
Linux is good for servers, and that's it.
We have a new hairyfeet, I see. I'm sorry, you're wrong, and there's nothing anyone can do to help you.