Apple lists a few limitations for APFS, one being: "Filenames are currently case-sensitive only."

My thought: hey, that is a feature!

It seems phrased in the particularly Apple-y style that usually means "we're seeing whether we're allowed to throw this legacy feature away or whether something will force us to put support for it back in."

More accurately: "we still need to see how badly this breaks Photoshop and iTunes or their builds."

Years ago, I used HFSX on my machine but I don't remember that iTunes broke because of that. A lot of other things broke though.

HFS+ can be configured to be both case-sensitive and not (the default). So in that sense it's a regression.

As I seem to remember running in case sensitive mode broke tons and tons of apps that made assumptions based on the history of HFS+ being case insensitive.

I'd be very interested to know if they run case-sensitive by default are not in the final release.

I finally understand a bug on OSX which bugged me for a long time. When I stored a file with the name äöü on and HFS+ volume and wanted to access this file via ä[tab] is would work. It was eventually fixed.

But know I know why this happened. HFS+ normalise the letter and ä becomes two characters, the a and the umlaut dots. And bash didn't know that or didn't care, so it so no file with an ä but with an a at the beginning.

Is this analysis correct? I so hope that APFS will be a little bit more sane.