No one said that stuff should change "unexpectedly" (and that's not
what currently happens either).
Actually its the opposite you want to consider the "whole picture"
when doing changes and not think
of independent pieces stuck together. That's why the "lets build some
core platform and put stuff on top
of it" is flawed.

Honestly, I keep seeing this argument in this thread, but it doesn't square with reality.  The concept of an OS and all of its apps as a monolithic distribution with a single release schedule is unique to Linux.  Every other major OS (with the exception perhaps of Windows) strictly differentiates between core OS and apps.  Some examples:

FreeBSD - installs a core OS  on which ports and packages are installed into a separate tree.  Versions of Ports are allowed to float independent of the BSD base.
PC-BSD - listing separately because in addition to the separation by FreeBSD, it introduces self-contained packages that even ship with their own libraries to keep the core clean
MacOSX - System is kept in a separate tree from apps.  Modification of System Paths is strongly discouraged.  Apps are installed in a parallel tree or as packages similar to PC-BSD.
Solaris - only ships with an extremely minimal system.  Virtually all apps must be install separately.

Windows ships a core OS but allows (at least in the past - can't speak to 8) installed apps and libraries to mix with system libraries.  But even they seem to be moving toward a more sandboxed model.


This is not to say that the Above OSs have it right, but to say a core / apps separation is fundamentally flawed is incorrect.  I would say the separation allows for more robust upgrades ( user-installed software doesn't taint the system tree) and more rapid upgrades of apps (a Libreoffice update should have to wait on the Kernel).

 


--
Mark Bidewell
http://www.linkedin.com/in/markbidewell