I'm mostly thinking about the composing. For example, the character '한' is composed with 'ㅎ', 'ㅏ', 'ㄴ'.
There are multiple unicode representations for each character, which means there's a one code point '한' representation and it's also allowed to have a 'ㅎ+ㅏ+ㄴ' representation. If the program is just naively searching through the code points the font is supporting, 'ㅎ+ㅏ+ㄴ' won't be rendered properly. (In the real world, most non-Korean companies that implement custom text rendering, even big ones like Adobe get this wrong.)
This only works if the text is (mostly) known upfront of course.
As far as I know this isn't needed for the Chinese and Japanese writing systems we are using though, only for Korean.
If people want their software to work well across the world, they should not use simple libraries like this. Unfortunately, software that gets it right is complex and messy. See "Text Rendering Hates You" for a taste of some of the issues, or some of my blogging about skribo (I tried to solve some of this for Rust but ran out of time on my contract).
So what I do is don't parse the font file fully, but store the location where litters live memory and only parse and render them when they are needed. Most CJK letters are never needed.
I don't have good support Arabic and Hebrew, they feel harder.
In my experience, it gets interesting with languages like Arabic which need special case handling for characters at the start and end of words, but those conversions can be applied before handing the UTF-8 string down to rendering. Oh, and the right-to-left rendering.
We have support for CJK and Arabic script in our game's text rendering, CJK was straightforward (only the massive rasterized font bitmaps are a problem), while Arabic was a lot more effort.
Other simple text rendering solutions also don't seem to have much of a problem with CJK (e.g. stb_truetype + fontstash):
https://floooh.github.io/sokol-html5/fontstash-sapp.html