Which lead to "DLL Hell" when the version of Whatever.DLL you had installed was not the same as the developer of your app had so the app wouldn't work, and if you switched to the one he had, some other app that used Whatever.DLL stopped working in stead. Which lead to the "exclusive version" / version-named DLL situation we have on Windows today... And, increasingly, on Linux.
I don't know exactly how shared libraries are loaded -- there are some tantalising mentions in sibling comments -- but it all seems to point towards two opposite solution paths:
1) Version-named libraries like on Windows; and/or, possibly, some file-link magic where /std_shared_libs/somelibrary/somelib_x points to /actual_libs/somelibrary/somelib_x_y_z, etc, etc... Then you could also have .../somelibrary/somelib_latest point to, well, the actual latest version installed, and somelibrary/somelib_default point to the one you want as default, etc, etc. (Hmm... Shouldn't stuff like this have been hammered out decades ago by, Idunno, some kind of Linux standardisation initiative... if this doesn't exist already, then WTF is the LSB for?!?)
2) Just fucking static-link everything already.
Friar William of Ockham seems to be pointing more towards one than the other of the above.
Anyway, what certainly doesn't look like a great solution to me is
3) Containerization. That just feels like "In stead of fixing DLL Hell on Linux, let's just ignore it, replicate ~half the OS -- but with our preferred version of every library -- inside a (pseudo-)VM, and pretend that running boxes within boxes within boxes is a solution". No, that's not a solution, that's a kludge.
Shared Objects (.so) are the Linux version of shared libaries.
I.e. they are an implementation detail, and if you don't use them as "shared library" (in general) then it won't really fall under this category.