> This is New Jersey approach again: "I'll make my code (the OS, the shell) easier to write, and in return make life harder for my users (the tool writers)".

I'm not sure if you're actually trying to argue for a specific position here, but you highlight several negative results of one "philosophy" of development, with the implication that the alternative wouldn't have those negatives.

This is a tricky point to refute because you're right, these are flaws and there could be a system that doesn't have them.

So why do these flawed systems exist and proliferate?

Because the real life result isn't actually a choice between "sloppy but quick to develop" and "elegant well engineered but slow".

The choice is actually between "sloppy but exists" and, well, nothing, because the other version never actually materializes.

(And of course, I feel compelled to point out that bash is a user interface not a programming language. Any attempt to replace it or improve it without focusing on that main point is doomed to failure, which is why you see so many people who apparently think that what bash really needs is strict type checking or something and end up creating a completely awful user experience)