I don’t quite see how Unix tools have trouble with spaces in filenames. Could you detail some cases where the space handling is not due to the shell, as opposed to the program being invoked?

There's this program called make...

My question was aimed at ops generic statement. As for Make, it originally wasn’t clear to me where the issue was supposed to lie. Lines in rule bodies are handed off to the shell, and that whitespace in rule dependencies need escaping didn’t seem surprising since it’s a list (though it’s probably a bug that whitespace in target names must be escaped, since it’s just one token that ends in a colon). But I see now that the expansion of list-valued automatic variables is probably a real Make-endemic issue.

> though it’s probably a bug that whitespace in target names must be escaped, since it’s just one token that ends in a colon

It's perfectly fine for a rule to have multiple targets, e.g.

  output.txt error.txt: source
    build source > output.txt 2> error.txt

Interesting! So in that case one could defend the need for escaped whitespace. Still leaves automatic variables, I guess.

Well it could be rewritten to use 0x1f (i.e. unit separator) to separate items. I mean it already has significant tabs. Though invariably people would be like "How is it acceptable for make to not support filenames which contain unit separators? It's 2020 guys, get with the program!"

Unix tools have no trouble with space in file names. "-", "\0", "\n" and bad Unicode are troublesome. Lazy programmers can forget to put quotes around variables in shell scripts, but it's not a problem of the tool.

Additionally, not every shell expands variables the way Bourne-based shells do.