I remember when the stated dream was to have a standard set of system-provided hooks that led to routines everyone would use for interfaces & more (think: Macin

I remember when the stated dream was to have a standard set of system-provided hooks that led to routines everyone would use for interfaces & more (think: Macintosh Toolbox / QuickDraw) while the main job of the developer would be to code the program logic. There was a great deal of talk about making any changes or additions be transparent — system calls would seamlessly fulfill the same task, even if the code behind them changed, & additions would be supersets of what came before, allowing older code to compile &/or run/function without a hitch, while giving newer software more capabilities. This was supposed to make maintenance easier, regularize interfaces, & at the same time keep code lean since it would rely so much on system calls (external libraries were supposed to be avoided, &c., &c.). This dream quickly fell apart (remember DLLs?), & it seems that much package management & packaging has to do with making sure the right libraries are available. It makes sense that it would not have worked as was hoped, as mass software development was still essentially in its infancy. Here's my question: now that there has been a great deal of collective experience in these matters, is it the case that it has been learned that this dream is simply impossible to bring about in a sane fashion (codebases may simply not be moveable to such a system without unaffordable effort), or has there been enough experience with the current messy state of affairs to drive people toward a modern attempt at making this actually work? If we're wanting fast, lean, stable, secure software (& all four may not be possible at once), I'm not sure that the current situation is heading toward those ends.