It is a permanent problem that several applications will have to be removed on updates due to unresolved dependencies. This could be improved easily by providing different linker versions of the same library instantaneously. Update packages within the same distribution could carry along elder linker versions of the upgraded library. Otherwise I would suggest a 'reduced' installation mode for just installing the dynamic library binaries so that multiple linker versions of the same library can coexist as part of different rpms at the same time.

  Sometimes the package managment system does not recognize that a library update will break a dependency and refrains from removing dependent applications:
> gedit
gedit: error while loading shared libraries: libgailutil.so.17: cannot open shared object file: No such file or directory
elm:~> locate libgailutil.so
/opt/gnome/lib/libgailutil.so
/opt/gnome/lib/libgailutil.so.18
/opt/gnome/lib/libgailutil.so.18.0.1

  In such a case (good luck) I can manually unload libgailutil.so.17:
> cd /
> rpm2cpio /media/dvd/suse/i586/gail-1.8.8-15.i586.rpm|cpio -iv '*.so.*'
> ldconfig
'reduced' installation outside the rpm database

  Sometimes even worse the library interface becomes subject to incompatible changes without assigning a new linker name. So it happened to the set/longjmp functions of /lib/libc.so.6 between SuSE-10.0 and SuSE-10.1. As a consequence of this all Modula-3 related programs crash on startup under SuSE-10.1 instead of returning a linker error. 
example: cvsup-16.1h-175.i586.rpm
see also: Modula-3 Mailing list 11.01.2007
Why is it not called /lib/libc.so.7?