> if I create two filenames that are identical except for normalization, how can the "human" layer possibly handle this? The "human IO" layer is responsible f

> if I create two filenames that are identical except for normalization, how can the "human" layer possibly handle this? The "human IO" layer is responsible for normalization of strings sent to the rest of the system. Therefore, your scenario cannot occur in normal operations. If it does occur, too bad. Some part of the system allowed an illegal operation, and you now have two filenames which may display as identical, but which are stored as different "buckets of bits". Your other scenario is the same. The issue of composed versus non-composed characters doesn't come up, as all input is normalized. If your human input layer can't normalize it, then tough. The system is broken. What happens when you create a filename on a "new" system, and then mount it on an "old" system? What happens when you add new code points to unicode? What happens when you create new composition rules? In your design, the answer is "oh, crap". The older file systems will make different decisions about name comparisons than a new file system. This leads to exactly the inconsistencies you're worried about. In contrast, the IETF design means all file systems always make the same decisions. "memcmp" always returns the same results. Old systems cannot create file names using new code points, because their "display IO" layer forbids it. Again, if such a string are created, then the system created a string it can't understand. The system is broken. It seems you have strong opinions here. These issues are being worked through in all internet protocols. The answer is not "fix every protocol to do string normalization and/or i18n". Wait 5 years. You'll see this design take over every internet protocol, and (IMHO) every new file system. Nothing else is workable.