OS X actually has perfectly fine support for shared libraries. They are supposed to be installed under /Library/Frameworks,
...and OS X keeps track of which installed applications use them, and either prevent uninstallation of shared libraries/frameworks that are used by installed applications or at least warn about it?
No, it doesn't - it doesn't even have an official uninstaller (although the ambitious can whip up a script to do that, such as the Wireshark uninstaller script I have; not sophisticated, though, as it doesn't dump the file list from the package manifest to figure out what stuff needs to be removed, it just has that knowledge wired into it).
And it definitely does not have a way to tie installable application A to installable shared library/framework X, so that installing A automatically installs X if A and X are separate packages from separate vendors.
That is the sort of "[management of] shared libraries/frameworks as installable objects separate from applications that use them" to which I was referring.
And, yes, that does sound a bit like the packaging management systems on some Linux distributions. From my limited experience with various Linux VMs on my Mac, they seems to work OK, but I don't have enough experience with them to say that there aren't problematic failure modes.
At least OS X frameworks have some support for versioning, so that if application A tested with version n of X and set up to require version n and application B is tested with version m of X and set up to require version m, they could be installed "side-by-side".
There's no reason why they couldn't do that on iOS as well, just let developers share frameworks on the App Store and build a mechanism into the App Store where an app can require other apps or frameworks.
And set up a framework (no pun intended) so that they can do the same sort of vetting of frameworks that they do on applications. Yes, that would be a Good Thing, but I'm not about to assume, without further information, that it's not that hard.