"Happening at a higher level" is a reasonable solution, if it happens consistently, no matter which higher level you're using. If you have 18 different functions to open a file, and 11 of them normalize and 7 don't, then you're screwed before you even get out the door. Programmers simply aren't capable of getting this right in a consistent way if asked to solve the problem application by application.

Higher level doesn't mean in app.

What I mean is that unicode normalization is really hard, and it should be it's own module that can be used regardless of the fs.

app->fopen->unicode normalization->APFS/HFS/FAT...

In that case, I agree. The problem here seems, from my understanding, to be that what Apple did was more like

    app -> CFFile -> unicode normalization -> fopen -> APFS

which screws you because anyone can just call fopen on their own without using the core foundation libraries, leading to inconsistent states in the filesystem. You can be higher level than the filesystem, but only a little bit. You can't be higher level than some API that developers will regularly use (unless you do like ZFS and normalize at lookup rather than create).

I guess the ZFS approach is the best one.

I'm not. The FS should be normalization-preserving/normalization-insensitive! http://cryptonector.com/2010/04/on-unicode-normalization-or-...