I agree with some of OP's points, but I think he could explain the mechanisms at work better. OP quotes the example of the 35+ command-line switches supported

I agree with some of OP's points, but I think he could explain the mechanisms at work better. OP quotes the example of the 35+ command-line switches supported by ls, some of which are clear violations of the 'Unix philosophy'. However, he moves on from this to suggest that users actively dislike using multiple tools to complete a task, and prefer a single all-purpose tool even if it results in that tool becoming very complex. So users would rather pass another flag to ls than learn how to achieve the same effect by piping the output from ls to grep, or sed, or what-have-you. I don't think this is the right way to look at it. Passing in additional flags is the preferred option not because users can't comprehend multiple tools, but because there's no discovery mechanism for finding out that using ls and grep together can achieve a particular outcome. The user's primary reference, the man page, provides no guidance here. Googling might help, as might asking a colleague, but by this point the cost of finding the answer begins to exceed the benefit. What Unix misses right now is a system to help users figure out how to combine operations. Yes, it's obvious once you know how, but for beginners it's really not obvious at all. The point is that there's nothing inherently difficult about doing things the Unix way, it's mostly a problem of documentation and discoverability. There's nothing that can compete with the single man page listing all of the options for a single tool in one place. This problem exists at higher levels too. Often web API documentation fails because it only tells you how to use the API in question, when a tiny bit of extra documentation on how to mash that API up with other popular APIs would be much more beneficial. If you want people to adopt your tool, you really need to tell them how to make it work with their other tools. I guess this is another example of the same principle behind the success of PHP - being 'right' is nowhere near as important as having documentation that tells people how to solve relevant problems.