There are different ways to handle that, but, in the main, it wouldn't need handling if you didn't use automated package management. In fact most of the work done by automated package managers is done just to correct problems caused by automated package management. That isn't intended to mean that there isn't any value in package managers, just that the value added is costly in terms of necessary overcorrection after the fact.
When you settle on a package-management method you kind of lock yourself in. You give control of your rootfs over to some schema or another, and its eccentricities are something you just have to accept from that point on, because thereafter any one file might be codependent on any other file and the only way to know is to unravel the whole web until you can see the bottom.
The package managers weave the web in, among, and atop the dynamically-linked library threads. Package-management solutions typically rely very heavily on dynamic linking - it makes it easier for the package-managers to version control if a whole suite of applications can source the same lib. And so where package managers mostly differ is in their various strategies for handling dynamic library versioning - especially in an FHS environment because the root tree is really the only other major variable piece of the puzzle. You have pointed out one of these typical of