Unix was a mistake

Exactly. It's just one of many, many pitfalls resulting from the "everything is a text file" principle: when it's in force, one program passing data to another (here — a list of files) has to serialise it into text, which the other program has to parse back. Both serialisation and parsing introduce potential for misinterpretations, bugs and unaccounted corner cases (say, failing to escape things properly). The potential is amplified when each program has its own parsing code written from scratch, which is very tempting when you deal with text (I recall a case, not that long ago, of someone using fscanf() to parse /etc/mtab, introducing an escaping bug, and then being told to use getmntent() instead). This cost of serialisation and parsing may be tolerable for one-time uses (when you know all the inputs that your program will ever process), but unacceptable when writing software that lasts.

If I were to design an operating system, I'd have the shell interpret command line arguments and pass them to programs as flags, abstract objects representing file paths (something like O_PATH file descriptors) and opened files (ordinary file descriptors). Pipelines would be based around passing abstract objects, not meaningless blocks of bytes. Incidentally, this would also improve security (because programs no longer need to access arbitrary file system locations) and solve so many other big and little problems (say, <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165>; the compiler would no longer output text, it'd output objects representing diagnostics).

I think some of the advantages of this approach may be actually attainable on Linux today, by means of passing file descriptors over sockets and memfd. But to actually get to the root of the problem, I think you'd need to redesign Unix from scratch.

Bah, I got a bit carried away. But I had to let off this steam somewhere.