Minor versions should be ABI-compatible so you should only need the newer of the two. For ABI-incompatible changes, a different SONAME is appropriate, though the convention would be .so.0 -> .so.1 etc.
> So if you want a binary to work across multiple distributions, you can build it on a really old CentOS and if you are lucky it will work, but I have no trust in this.
As far as glibc or other libraries that take ABI stability seriously go, this does work.
> Forward-compatibility is not really considered, where you update your libraries and your existing app becomes more powerful.
Symbol versioning does not prevent you from updating the implementation of old symbol versions in a compatible way.
> The dynamic linker doesn't allow you to load two different library versions at the same time (without a lot of contortions). You would think you could do `dlopen` and `dlsym` on two different `.so` files, and then just have separate function pointers to each version's functions. But the linker loves to load all the symbols into a global namespace for some reason.
Having an option to use a separate linking table for specific dlopen calls would be useful, yes.