Because I want to?

Well an uppercase ASCII char is a different char than its lowercase counterpart. I would argue that not differentiating between them is an arbitrary rule that doesn’t make any sense, and in many cases, is more computationally difficult as it involves more comparisons and string manipulations (converting everything to lower case).

And the result is that you ultimately get files with visually distinct names, that aren’t actually treated as distinct, and so there is a disconnect from how we process information and how the computer is doing it.

‘A’ != ‘a’, they are just as unequal as ‘a’ and ‘b’

Edit: I would say the use case is exactly the same as programming case sensitivity, characters have meaning and capitalizing them has intent. Casing strategies are immensely prevalent in programming and carry a lot of weight for identifying programmers’ intent (properties vs backing fields as an example) similar intent can be shown with file names.

Think the other way around: What’s the use case for case insensitive file names? Does it justify the effort and complexity for the filesystem and the programs to know the difference between lower and upper space chars?

On Mac when I rename a folder from “FOO” to “foo” git sees them as the same folder so no change is committed. In JavaScript I import a file from “foo” so locally that works. Commit my code and someone else pulls in my changes on their machine. But on their machine the folder is still “FOO” so importing from “foo” doesn’t work.

What’s a windows?

Iirc they’re indexes for the system wide search feature, Spotlight

ehthumbs_vista.db

Metadata that’s a holdover from the 1980s MacOS behavior. Hilariously, today, NTFS supports that metadata better than Apple’s own filesystems of today. They can hide it in Alternate Data Streams.