it is frustrating that nowhere does it tell how it actually works. generally keyboards can not send specific unicode codepoints to host system, they only send scancodes that get interpreted by operating systems keymap. But most keymaps do not define any keys for these symbols, so there is something going on here. Based on the docs, I'll guess it attempts to send a sequence of keypresses to trigger some compose mode (thus requiring additional software on windows). I find such hacks slightly frustrating because they are so fragile, they depend on the keyboard predicting perfectly how the host will handle the keypress sequences which obviously can break quite easily, e.g. simply by switching layouts or having some timing/focus related aspects.
I would really love to see new keyboard HID designed specifically for modern advanced keyboards (qmk etc) where you wouldn't need to resort on this kind of trickery. Or alternatively make the input stacks of OSs more easily configurable with custom physical layouts and modifiers etc instead of assuming that all keyboards follow basic ISO/ANSI layout.
Ya, I was right. The driver is built around popular QMK framework. Here you can read how it handles unicode input: https://docs.qmk.fm/features/unicode.
It's likely the driver handling the conversion. Which makes me wonder, can I use the same driver to remap extra keys on my existing QMK compatible keyboard?
Maybe it's as simple as sending popular ALT+<unicode> sequence, at least for Windows and Linux. But that's still hacky.