But I don't think that it is an unsolvable task. If you simply use Unicode-aware version of "to lowercase" function, it will be better than what we have today. But of course there is a place for improvement (dealing with accented letters in European languages, dealing with combining characters, different alphabets like Hiragana/Katakana etc).

Hum... I think simpler is better, and having each letter be what they are only seems much simpler than having to guess if the file system is going to decide my new file name is equivalent to another existing file name and overide it rather than creating a new one (for example).

It is "simple" for a programmer who doesn't want to learn Unicode and prefers working with bytes instead of letters, but inconvenient for a user. More keypresses, easier to make a mistake when typing.

I cannot imagine a situation where you need two files whose names differ only in case.

Since it's relevant and funny, I'll quote the famous rant of Linus Torvalds on the topic (it was because of issues it caused with Git, but I assume it still means it's unlikely Linux will ever follow this path ^^)

"The true horrors of HFS+ are not in how it’s not a great filesystem, but in how it’s actively designed to be a bad filesystem by people who thought they had good ideas.

    The case insensitivity is just a horribly bad idea, and Apple could have pushed fixing it. They didn’t. Instead, they doubled down on a bad idea, and actively extended it – very very badly – to unicode. And it’s not even UTF-8, it’s UCS2 I think.

    Ok, so NTFS did some of the same. But apple really took it to the next level with HFS+.

    There’s some excuse for case insensitivity in a legacy model (“We didn’t know better”). But people who think unicode equivalency comparisons are a good idea in a filesystem shouldn’t be allowed to play in that space. Give them some paste, and let them sit in a corner eating it. They’ll be happy, and they won’t be messing up your system.

    And then picking NFD normalization – and making it visible, and actively converting correct unicode into that absolutely horrible format, that’s just inexcusable. Even the people who think normalization is a good thing admit that NFD is a bad format, and certainly not for data exchange. It’s not even “paste-eater” quality thinking. It’s actually actively corrupting user data. By design. Christ.

    And Apple let these monkeys work on their filesystem? Seriously?"

I can think of one. When we write (say "ES6") modules it makes sense that the name of the module-file without extension should be the same as the value exported by that module.

Inside the module you'd prefer to follow conventions like name classes title-case and name functions camel-case.

Thus you might have one module exporting a class named "Camel", and another module exporting a function named "camel". You could then have two files, Camel.js, and camel.js in the same directory, containing two separate programs.

> If you simply use Unicode-aware version of "to lowercase" function […]

There's no such thing. What's the lowercase of ‘I’ — ‘i’ or ‘ı’?

That's the "place for improvement" you shoved into the "[...]".

Pick something.

Pick something? Whatever you pick is wrong for some users.

And busted unicode support is more wrong.

Also you don't need to have an opinion on how to lowercase, you can just say that İIiı are equivalent and it shouldn't make people that upset.

Case-insensitive ASCII filenames are best filenames.

Also, please, no whitespace in filenames. Allowing linebreaks is just insane.

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.