> Every natural language uses spaces to separate things.

Exactly. To separate things. Which, incidentally, happens to also be precisely what make, and the traditional UNIX shells do :-)

The problem isn't that space in itself is a particularly difficult character. The problem is that its meaning is overloaded and ambiguous. No matter what you do, computers will have difficulty with ambiguity. You'll always have the problem that the separator is special, but hey, I'd be all for using 0x1C instead ;)

How exactly is this different to, say, maths, where there is an assumed precedence and when you need to either make that clear or change the order you use parentheses to encapsulate the inner calculation?

What it sounds like is that the Unix shell syntax was established how it was, everyone built on it with all of its syntactical conveniences, and suddenly there's 100% buy-in to the idea that a computer just can't handle a filename with spaces in a shell.

    ./cmd do-something-with --force file with spaces


    ./cmd do-something-with --force 'file with spaces'

That's one of the main problems solved. If you're expecting to run an executable with spaces in it, like this:

    ./do something with cmd --force 'file with spaces'

Then it's another problem but one that can be solved by convention. A GUI can happily execute `./do\ something\ else` but if you're in the shell you've got completions, aliases, functions, symbolic links...

And if that's not ideal, then `./'do something with' cmd …` should be good enough right?

You can prevent your tools from having to deal with the fact, by preprocessing.

> Every natural language uses spaces to separate things.

Nope. You don't space out each word when speaking. If you were speaking about writing systems, not all writing systems use spaces as word delimiters. See: https://en.wikipedia.org/wiki/Space_(punctuation)