Здравствуйте, пффф, Вы писали:

П>Но ведь это ничего не значит, потому что один глиф (или как правильно сказать?) может состоять из нескольких codepoints, так?
АФАИК, глиф составляется из нескольких codepoints только одним способом: все, кроме первого — это combining characters.
Поэтому навигируемcя путём анализа категории уникода для каждого code point до тех пор, пока не наткнёмся на не-combining character (что-то вне категорий Mc/Mn/Me).


П>В винде, допустим, должны быть какие-то функции на эту тему (кстати, какие?).
Ну, в дотнете это делается легко: https://learn.microsoft.com/en-us/dotnet/api/system.globalization.charunicodeinfo.getunicodecategory?view=net-7.0#system-globalization-charunicodeinfo-getunicodecategory(system-int32)
Внутри оно устроено не шибко сложно:https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Globalization/CharUnicodeInfo.cs#L384
То есть идёт некий лукап по таблице. Полагаю, что при нежелании писать на дотнете таблицу можно выковырять из исходников и перенести в любой язык программирования.

П>Кстати, некоторые раскладки в винде могут генерить целые пачки символов — лигатуры, например в персидском аж до 4х WCHAR может быть за одно нажатие. А отображается — как один символ. Тут явно больше одного UTF-32 codepoints. Если они могут быть подвергнуты композиции — то почему это не сделано? А если не могут, то как по ним корректно итерироваться?
Я в арабских языках не силён, но насколько я знаю, там преобладают именно что лигатуры. Но если там действительно речь идёт не о визуальном соединении нескольких символов вязи, а о комбинациях — то да, значит для них в уникоде нету precomposed characters.
Итерироваться корректно — именно вот так, по базовым символам.