When necessary you can make an auto-expanding volume that's case-sensitive and leave your host FS alone. I have not found that I really want to have differently-cased but otherwise identical filenames in the real world at any point though.

Ages ago, I heard from co-workers at a company that I had left that there was an issue because of some file-naming in a PHP application that they were trying to run locally on a Mac. There was foo.php which was the interface and Foo.php which had a class definition in it.

What idiot would name files like that? I said.

You, they answered.

I don't do that sort of thing anymore.

A bug that affects my teams once every few years is a developer will create a file named "A.txt" check it into Git, realize it should be "a.txt" and rename it, and then basically everything will shit the bed and you waste a day figuring out why nothing is working.

A related bug is a developer will make a webpage called /a/ but link to /A/ and then the link will be broken in production. At this point, I have seen this same bug enough times to be able to fix it reasonably quickly, but it definitely wastes time for the team.

Yeah, my current company encourages development in a case-sensitive volume and I assume this is why. But this is more an issue of your development environment working differently than prod than a problem with the notion of case insensitivity per se.

We added a commit hook to block case conflicts.