I think one criterion could be that you should be able to identify a name by its pronunciation. The same utterance should always refer to the same thing on the computer. When you speak you don't speak line-breaks. By the same logic commas should not be allowed in names. And when you speak we don't typically hear whitespaces either.

By the same logic the whitespace sensitivity of Python is a bad idea. :-)

My criterion is that paths should not be painful to type, parse, or copy-paste. So no keyboard layout switching, and escaping should not be necessary. Lower-case Latin letters, digits, periods, and dashes (of the unique variety that's available on keyboards, and not in the initial position) are simple and enough.

I wouldn't mind but there are a bunch of people in this world who have no idea what those ASCII symbols even mean, and who might prefer using symbols they understand ^^

Those people do not use filesystems.

Also, my native language does not use the Latin alphabet. Attempts by American companies to be more inclusive and internationalized are often misguided. MS is especially nasty with its translated formula functions in Excel, but having differently named filesystem paths in different alphabets depending on the phase of the Moon or something is also very inconvenient.

Oh yeah Excel (or libreoffice) is really awful to use in another language, I often have to force it to English because of the formula mess. But I guess that's a developer-who-can-speak English point of view.

Nah, the names of Excel functions are nonsensical in any language, and you still need to know the English ones.

Though I do have to admit that I do not know what, e.g., ASCII code 8 would mean in a filename. Or 27. I’d very much prefer using symbols I understand.

Filenames with terminal control escape sequences are lots of fun.

Limiting possibilities to just lowercase Latin, numbers, periods and dashes (in non-initial positions) decreases chances people see symbols they do not understand by a lot.