For example, making it so key applications and development stacks could
easily float from one base OS to the next would make it less of an issue
when the base OS needs to be upgraded.

Not sure I catch your drift here, but it sounds like it could cause API mismatch headaches.


It underscores the need for the base OS or core to be absolutely as small as possible.  FreeBSD provides a good model, small installed system customized with packages/ports.  Personally I would like to see a three-level approach:

Level 1 (Core) - OS Kernel, command-line utilities, C/C++ compiler and libc - moves the slowest.
Level 2 (System) - Dev Libraries, interpreters (Python, Ruby, etc), X11, KDE/QT, GNOME, etc - moves faster.
Level 3 (Userland) - LibreOffice, Firefox, Games, etc.

A major change to one level should cause a rebuild of higher layers to avoid the API issues you mention.  Changes within a layer should be independent.  I would propose change rates of:

Level 1 - 12-18 mos
Level 2 - 6-12 mos
Level 3 - release as soon as stable packages are available.

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