> /usr/bin/python should be whatever I want it to be.
Why /usr/bin/python? /usr/bin/ has been for ages the "system" area - why would you want to suddenly usurp it for yourself?
/usr/local/bin/python will on most Linux systems be executed ahead of /usr/bin/python, because /usr/local/bin/ usually precedes /usr/bin/ on the $PATH. Thus you can have your cake and eat it too.
> The bottom line I guess is that mixing core OS components and user installed software in the same directory structure with no way of differentiating them is simply bad design.
Linux distro makers agree with you - if you do not customize environment variables, user-installed software goes into /usr/local/ and the OS package-management (which can be considered "system" I guess) puts executables into /usr/{bin,sbin}.
This tends to work well as long as you keep in mind that everything outside of /usr/local/ (or your customized installation path) may at any update change subject to the will of the "system". I think this is a reasonable setup - it gives the OS vendor the ability to update the system, while giving you free reign in your /usr/local/ playground.
OS package-management (which can be considered "system" I guess)
This is where I and the distro makers disagree. When I use synaptic to install the latest version of foobar, that is not in anyway "system" and foobar should not be dumped in the same directory as core system binaries. There should be a directory that contains everything core to the OS (like python 2.4), which was only updated by the OS updater routine (which should be different from the update all the software I've installed routine). Then there should be a directory which contains everything I've chosen to install (like python 2.7) which is where everything that I install via whatever is the normal way to install things on that OS ends up. I don't care too much about what these directories are called, but having them be the same, as it is now, is not an ideal solution in my mind.
We're getting into the debate of what constitutes a "core system", and I'm afraid there's as many answers to this question as there are debaters.
As far as the update routines are concerned - you can already have those, by self-selecting which packages do you want to update. As a pro-active measure, you can even lock down packages which should never be updated.
This seems to be fine to me - the advanced user has the means to control the update mechanism, and the casual user can just do an all-encompassing "apt-get upgrade" or an equivalent to make sure that she has all the security fixes.
It seems like you want BSD ports, or some alternate package repository that has /usr/local as the root. The packages from the OS repository are the OS.
Why /usr/bin/python? /usr/bin/ has been for ages the "system" area - why would you want to suddenly usurp it for yourself?
/usr/local/bin/python will on most Linux systems be executed ahead of /usr/bin/python, because /usr/local/bin/ usually precedes /usr/bin/ on the $PATH. Thus you can have your cake and eat it too.
> The bottom line I guess is that mixing core OS components and user installed software in the same directory structure with no way of differentiating them is simply bad design.
Linux distro makers agree with you - if you do not customize environment variables, user-installed software goes into /usr/local/ and the OS package-management (which can be considered "system" I guess) puts executables into /usr/{bin,sbin}.
This tends to work well as long as you keep in mind that everything outside of /usr/local/ (or your customized installation path) may at any update change subject to the will of the "system". I think this is a reasonable setup - it gives the OS vendor the ability to update the system, while giving you free reign in your /usr/local/ playground.