Actually, I kinda like not having the possibility of having both "Downloads" and "downloads" by mistake in my home folder.
Case insensitive filesystems made more sense decades ago than they do today. Case insensitivity is fundamentally a UX feature that has been implemented in the wrong layer. Rather than the filesystem itself being case insensitive, the search functionality in GUI interfaces to the filesystem should be case insensitive. And furthermore, the user should never be typing out the complete name of any file that already exists, because everything should provide auto-completions of existing filenames.
For one somewhat recent example: CVE-2014-9390 git: arbitrary command execution vulnerability on case-insensitive file systems. (Also affected mercurial IIRC.)
Once, a colleague working on Linux created two files with same name but different case, and committed them to the Git repo, and then I tried pulling it on my Mac. I don't remember exactly what happened next, but I wasted a lot of time trying to sort that mess out.
(There was no real reason for them doing this, it was just a mistake on their part, and they didn't notice they'd done it before committing the files.)
It seems to me that most problems with case insensitive file systems are rather problems because there are different file systems out there. Just as there always is with "competing" standards.
Let me put it briefly. Much Linux software is multi platform and vice versa; this is how being the "underdog" (quotes cause servers) works. When you look at the transitive closure of the dependency graph, all sorts of case-insensative assumptions will pop up.
I'm on a shop where all developers run Linux on their laptops, but we work on tools and libraries that are supposed to run on macOS for all those other developers. Supporting them is a huge pain.
I like it when apple iOS-ifies macOS making development harder. Hopefully it brings people out of denial.
Unicode allows different forms that lead to the same representation for the user.
Gödel.txt may be written as - G-\u00F6-del.txt where \u00F6 is "Latin Small Letter O with Diaeresis" or - G-o\0308-del.txt where \u0308 is "Combining Diaeresis"
From user perspective they are indistinguishable.
Traditional Linux filesystems do not normalize this in any way. MacOS filesystems normalize it to decomposed form with "Combining Diaeresis" (which is mad). NTFS does not normalize, but windows apis behave differently - if you create NFC+NFD Gödel.txts under same directory then you will either see both, see one, or even see both, but be able to select only first from system "open file" selector.
I too hate windows because of it's case-insensitivity but that's not the problem here. The problem is a messed up Include-Path and/or the shitty naming/placing of C/++-standard-headers.
It’s amusing and frustrating that you use a lowercase W here, expect everyone to know what you mean, while arguing in favour of case-sensitive filenames - the user-hostile systems which would stubbornly refuse to know what you mean.
What I've never seen is an easy way to convert a case insensitive file system into a valid one after the fact. It would be great to give people an easy way to fix it after the fact.
https://www.quora.com/Why-does-OS-X-choose-to-have-a-case-in...
Perhaps Mac users should just apply a patch and let everyone else use case as a differentiation.
Before that, I knew people who did it with zip drives. And I even once knew a guy who tried it with DVD-RAM, but gave up pretty quick.
("If you can't say something nice ...")
Even Microsoft is abandoning it as a place to keep source code. At least, their own source code. Windos is not built from a tree on NTFS because it's too slow.