I am not a fan of Solaris's long standing refusal to touch anything.
This is what people often deeply misunderstand about traditional UNIX operating systems: one of Solaris' greatest features, in stark contrast to GNU/Linux, is the insistence on not breaking backward compatibility. Solaris has however delivered less(1) as standard since Solaris 8, so there is nothing stopping one from configuring their PAGER to it. In fact, I do the exact same thing in my OS builds of Solaris and SmartOS. It's called system engineering.
illumos has the entire GNU userland in /usr/gnu and it's packed with new features under the hood, but those will almost never be introduced such that they break someone else's stuff; it's the very advantage differentiator illumos provides over anyone else! And it's good engineering, adding new funtionality while not breaking existing one.
Features are use-case specific. One person's feature is another person's bloat. (Personally, I side with the article author on this.)
Or, are you responsible for delivering any services, and if so, do you not mind when someone else's changes cause you an outage?
Perhaps you have some private automation in place; do you not mind if your automation breaks because of someone else?
Apropos bloat, illumos is the only operating system codebase which gets faster and more efficient with every commit. If there are others out there, I have yet to see such a thing.
I'm happy enough if people say "okay, we didn't get this quite right, but we learned and we've made it better". And if the new approach isn't compatible, well okay. The short-term pain is usually worth moving forward in the long-term.
And when this happens, it's usually not a technical issue anymore, but a communication issue, which is a way harder problem to solve. If your solution to the communication problem is technical, i.e. let's always maintain backwards compatibility, then there's still the issue of communicating what the new, preferred method is. So I feel that if you have great communication with the people who care, it shouldn't impact them badly in the first place.
The danger of backwards compatibility is maintenance cost, and stifling new ideas to solve an existing problem better - people won't bother, because the effort of making something new would be overshadowed by the effort to retro-fit old behaviour.
Still though, I get the point of changing stuff just for the sake of change is bad. I'll ignore the hyperbole about illumos though.
And the fact is, when there's a piece of core that nobody uses, and has since been replaced by superior tooling, The Right Thing to do is to rip it out, and link to said superior tooling if it has a compat mode. I mean, it's not like Solaris still has ptrace or /dev/poll.
...The only way that could ever work without breaking existing software running in the wild would be for that superior tooling to be backwards compatible. SunOS (illumos) does this all of the time. For example, GNU options like -C have been added to SVR4 tar(1) on illumos, thereby enhancing, but not breaking existing functionality.
Otherwise, how would you determine whether someone isn't using something, and that on every Solaris / illumos system on the planet?
Have they optimized grep the way GNU did?
I don't know about grep(1) in particular, we have fgrep(1) on illumos for that, which comes all the way from AT&T's SVR4. We also have egrep(1) in addition to grep(1). HP-UX for example, being a SVR4 system, has fgrep(1) and egrep(1) in addition to grep(1) as well. I use fgrep(1) every day; only when I need to use regular expressions do I use grep(1).
I know cat(1)'s been optimised. If you're curious enough, you can check out Solaris's grep(1) code here:
Lupus in fabula: you can also see that the -H option has been added to grep(1), which illustrates my point that illumos does this all of the time.
I mean, it's not like Solaris still has ptrace or /dev/poll.
% ls -l /dev/poll
lrwxrwxrwx 1 root root 29 Jul 24 2013 /dev/poll -> ../devices/pseudo/poll@0:poll
% man ptrace
Standard C Library Functions ptrace(3C)
ptrace - allows a parent process to control the execution of
a child process
int ptrace(int request, pid_t pid, int addr, int data);
% uname -srpmi
SunOS 5.10 i86pc i386 i86pc
My main point was that if you have a superior utility that doesn't break compatability, like less, than why ship the original? Less is better than more, and it doesn't break compatability in any way I know. That's why setting it as $PAGER works.
The fact is, a lot of superior tooling is backwards compatible. PCRE (although superior is up for debate) is fairly compatible with extended regex, GNU tar is compatible with posix tar, both syntactically, and semantically with the aid of -H. Heck, it's compatible with the v7 archive format.