[1] In Unicode, they're generally unified into a single set, via process called "Han unification". So, unlike Greek "Α" vs Cyrillic "А", the "same" character that may even look slightly differently in Chinese vs Japanese (e.g. "海"), would have a single codepoint in Unicode. But that's another story...
To reiterate:
• Chinese characters are called hànzì¹
• modern Japanese uses many hànzì, calling them kanji² instead
• katakana³ is used in modern Japanese to write words of foreign origin (loanwords) as well as onomatopoeia and is romanized as katakana, not katagana
• hiragana⁴ is used in modern Japanese to write okurigana⁵, particles, and certain words, and is romanized as hiragana, not hiregana
Here’s a typical (and extremely simple) sentence in modern Japanese that uses all three:
この文はサンプルです。
This is a sample sentence.
この: this (hiragana)
文: sentence (kanji)
は: particle (pronounced wa) (hiragana)
サンプル: sample (loanword; pronounced sanpuru) (katakana)
です: particle (pronounced desu) (hiragana)
――――――
¹ — https://en.wikipedia.org/wiki/Chinese_characters
² — https://en.wikipedia.org/wiki/Kanji
³ — https://en.wikipedia.org/wiki/Katakana
(While we're being pedantic)
です isn't a particle, it's the imperfective (present/future) polite form of the copular verb (to be, in English). The only particle in that sentence is は.
And as a further side note, some words or names normally written in kanji or hiragana are ocassionally written in katakana for emphasis or to emphasize a foreign nature.
Fixed
Which part of it is relevant to pathnames?
> To the canonical form of course
Do you mean NFC?
> not the crazy Python 3 or Apple idea of NFD.
In what circumstances does Python 3 normalize pathnames?
> If it's encoded as bytes you get garbage in - garbage out.
What do you mean by "encoded as bytes"?
> http://perl11.org/blog/unicode-identifiers.html
This is about programming language identifies, not about pathnames, which are very different beasts.
All parts regarding identifiers and names, if you see pathnames as publicly identifiable information. See below.
> In what circumstances does Python 3 normalize pathnames?
None. Python 3 normalizes identifiers to the shorter non-canonical NFKC form. Apple HFS+ normalizes pathnames to the longer D canonical form. Which is faster but takes more space. Usually space is more important than CPU.
> What do you mean by "encoded as bytes"?
What everyone else means on byte encodings: 1-1 mapping of bytes, without any further knowledge of the encoding.
> This is about programming language identifies, not about pathnames, which are very different beasts.
Partially. pathnames can also be argued to be identifiers, similar to domain names, email names, user names, language identifiers. Apple does so. Ask plan9 what they think about pathname semantics. Not everyone is in the garbage in - garbage out camp. Many systems do encode pathnames and have character restrictions. Esp. important is the popular / spoof, which people from the garbage camp don't care about. Julia is recent proponent of the garbage camp, btw.
What definition or sense of 'canonical' do you mean? NFKC stands for "Compatibility Decomposition, followed by Canonical Composition", so it's canonical in some sense, right?
That's fortunate, not unfortunate. I want the files corresponding to documents to be named according to the titles of those documents, and said titles often do mix Latin and Cyrillic scripts in a way that produces "confusables". So as a generic rule for all filenames, it's a no-go - it will significantly affect perfectly legitimate use cases.
1) History has shown that doing it at the filesystem level causes significant compatibility issues
2) Case insensitivity can present visually confusing results
3) Round-tripping between cases sometimes is not possible without loss of information
4) Some languages don't have a meaningful definition of 'case insensitive'
5) Some languages would demand a more comprehensive approach (i.e. being able to search using either kana or kanji for Japanese filenames)
So for things like case insensitivity (or #5 above) it's best to handle them at the application (or, ideally, OS user space library) level, taking advantage of information like system locale. Low-level APIs and system services can use case-sensitive filenames.
This is different from the question of whether to normalize filenames, because filenames are still visually unambiguous (at least most of the time) in UI, logs, and debuggers.
Incidentally, Windows is proof of this technique's advantages because NTFS is a case-sensitive file system while Win32 is case-insensitive. IIRC the Linux subsystem for Windows takes advantage of this.
Identifiers should be identifiable. If a filename is encoded in utf8, it needs to be normalized. To the canonical form of course not the crazy Python 3 or Apple idea of NFD. Which is also slower. If it's encoded as bytes you get garbage in - garbage out.
There's much more to consider, but unfortunately you cannot restrict a directory to forbid mixed scripts or confusables. I summarized a few problems at http://perl11.org/blog/unicode-identifiers.html