> And no, static compilation is not a solution, people do care how much memory their applications use (observe Mozilla's and LibreOffice's tremendous efforts towards that goal), and they shouldn't have to upgrade all their applications just because a vulnerability was discovered in one of the fundamental libraries.
I may be completely off here, but I suspect that most libraries are so small (taking into account that parts of them won't be used by the application) that static linking won't be a big problem, and that many of the remaining libraries will be sufficiently exotic that only one or two applications will be using them anyway, and the gains from dynamic linking will be minimal or not. So it might be worth thinking of strategies to deal with libraries which don't fall into either category (like the Gtk+/Qt complexes, which in any case don't take well to multiple versions in use on a single system - perhaps using the system Python interpreter to access the system versions?)
Regarding vulnerabilities, perhaps this could be solved by distributing applications compiled but unlinked, so that just the vulnerable library needed to be updated? One might even find some half-way house between the way free software distributions work now and a fully do-it-yourself approach which would let multiple pieces of software get updated together. Though I suspect that for most software smaller than Mozilla or LO the gain would probably not be worth the effort.