Your clarifications are helpful, but your initial post certainly didn't imply such nuance. Regardless, I appreciate you taking the time to better explain your position.
With that said, I still disagree with your conclusion that Sun and Oracle has no "cultural tradition of taking toolchain usability seriously". Again, I strongly disagree and believe that does not apply to all products or projects.
Perhaps it doesn't apply to the degree that you want, but you are claiming that it doesn't exist at all, and I can assure you that was / is not the case based on people I know that have worked on many of those projects.
At multiple employers, having spent 6-8 figures on Oracle
database or enterprise business applications, we used to
get things like critical security updates delivered as a
ZIP file with instructions for where to copy files and
what permissions to set them. Sure, it's not that hard to
roll a pkg, rpm, etc. but why should every customer need
to do that?
I completely agree that there should be a better update system; Sun was already working towards a better one which was first introduced in Solaris 11: The Image Packaging System. It was a new packaging system intended to simplify software updates for all of Sun's Solaris customers. The Glassfish team also chose to leverage for their product, distributing updates for Glassfish on Solaris, Windows, Linux and even Mac OS X via IPS.
Sun wasn't ... it took 20 minutes to have the systems in
production running Debian Linux and we spent less time on
OS support over the life of hardware than trying to get a
core feature to work once.
I sympathise, but again, this is why a completely new packaging and installation system was introduced in Solaris 11; to avoid problems like that. It helps ensure administrators have easy access to updates and always performs OS updates in a way that can be easily reverted if there's a problem.
If that's even mildly interesting to you, there's a website where both the FOSS source code for the new packaging system and the reasoning behind it is available:
https://java.net/projects/ips/pages/Home
The "Background Reading" section on that page has several helpful links that talk about the reasoning and philosophy behind it.
Solaris 11+ has a great update story compared to pretty much any UNIX-like system out there today. To update to the next release of the operating system, it's generally as simple as:
pkg update
Now behind that simple command lies an entire set of processes that happen each time it is executed:
1) newest "package catalog" is retrieved from the configured package repositories (local and/or remote)
2) determines which packages are installed, and what all of the newer versions of those packages are
3) parses dependencies of all packages involved to establish the transitive closure of the dependency graph
4) transforms dependencies into a set of boolean statements that can be evaluated by minisat, the boolean satisfiability solver that's used
5) takes the solution (if one is available) provided by the solver and then maps that to the equivalent set of packages
6) retrieves package manifests for all packages that will be upgraded, added, or modified
7) determines differences between installed version and target version ensuring that only files that have changed between package versions are retrieved and only files that need to be updated, installed, or removed are modified
8) organises differences based on the order they need to be executed as a single set ignoring package boundaries, performing reference counting and conflict checking
9) retrieves only the files that will be upgraded or installed as part of the operation
10) determines if the operation can be safely performed on the live system, if it cannot, it will create a snapshot of the root filesystem and clone it, otherwise, it will take a snapshot of the filesystem as a precaution before execution
11) executes planned operation, executes commands that prepare new boot environment for use, etc.
12) if operation succeeds, new boot environment (if applicable) is activated
Or put more simply, when you execute 'pkg update' on Solaris 11+, generally only a copy of the system is updated. So if the update fails, you can just pick an older boot environment from the GRUB2 menu and be right back to a working system in moments.
The other big difference from all of this, as an example, is that the package system is capable of upgrading from any older version of Solaris to any newer version of Solaris.
There are no patch readmes or zip files; administrators just update from one version to the next -- the system figures out the rest. It even knows when upgrades require a firmware update.