My primary complaint about Unix CLI is that the commands try to do two disparate things simultaneously: outputting text for humans and generating data for consumption by other commands. In a properly designed command line ecosystem (it's far, far too late for that now), there would be good human readable output in one mode, and tools would exchange structured, already escaped data amongst themselves in another mode. Alternatively, the shell would render the output for humans, and tools would just communicate in machine format.

Consider for example executing a compression command on all jpg files in a folder and below. Currently, the syntax goes something like this:

  find . -iname "*jpg" -exec gfxcompress {} \;

Naive Unix users would have expected this to be achievable by piping, but no! In reality there is a special syntax of the find command that does this, and it's not completely clear how you would deal with file names further down the line, or how you would achieve further chaining. This syntax is also completely unique to the find command. You can't just plug in another data source and perform the same operation. In a CLI where tools are designed to be chained, it would look something like this:

  find | match :name="*jpg" |> gfxcompress :name 

In this example I used an imaginary |> operator to indicate I want something performed on every item, and I can refer to the "name" field of each directory entry directly. If I wanted to filter by time, for example, I might use the :time field instead, without any need for explicit support. If I wanted to mutate the name somewhere in the chain, I could do it. If I wanted to chain additional commands, it would be obvious how. And it would just work.

The same goes for error handling. Imagine a compiler spitting out structured error information which you could use directly in other tools without having to parse and interpret it first.