like this

I respectfully disagree.

Consistently broken in the same way for everyone is better than unreliably working for some people, reliably working for other people, unreliably broken for a third group and reliably broken for a fourth group.

Filenames should be created as the user typed it - don't change the input before storing it.

Filenames should be displayed as the user typed it - don't render output different to what was input.

Tools should match filenames as the user expects it - in this case (hehe) it should perform a case-insensitive match. Ambiguity resolution has to be performed in the case where there is more than one match.

    cat > MyFile.txt    # Create 'MyFile.txt'
    ls                  # Display 'MyFile.txt'
    echo myfile*        # Display 'MyFile.txt'
    vim myfile.txt      # Opens 'MyFile.txt'

Another issue with this is that userspace calls to `open()`, `stat()`, etc aren't able to fail and return a list of case-insensitive matches in the case of ambiguity. This makes handling the ambiguity the applications (very complex) problem - before any `open(fname)` call, the application will first have to `scandir()` to get all the filenames, then perform a case-insensitive match against the list to get all the CI matches, then prompt the user to select the correct one.

> The fact of the matter is, two out of the three most used systems today are case-insensitive

I think it's more that they are case-aware than case-insensitive; after all the filesystem certainly stores the case, and they both retrieve the case correctly.

It's the tooling that faces the user which "fix" cases to prevent two files with the same name in different cases being created.

You can certainly create file 'FOO' and file 'foo' on Windows in the same directory, and then the tools tend to randomly open only one of them no matter which on the user clicked on.[1]

Which is why I say that the actual filesystem is case-sensitive. The user programs normalise the case for the user.

[1] EDIT: I accidentally did this once, and had to write another small tool to remove files with the filename as typed because the normal tools (del, explorer.exe) just randomly choose one file to remove.

You are the one who wants to introduce extra complexity: A few narrow corner cases where the filesystem treats certain code-points as equivalent. Imagine how confusing that would be to someone who doesn't regularly use those code-points.

Less that 20 years ago. Not a small project.

I rather think you need to solve at least a somewhat significant subset of a problem in order to justify the extra complexity of the solution (and any confusion caused by it not solving the whole problem). Believe me, I'm a great believer in "perfect is the enemy of good", but not to the extent that I think that "any shitty solution at any cost is better than nothing". I'm not convinced that case insensitivity doesn't fall in the later category.