Windows user font directory, KnownFolder API and the preferred way to register fonts in behalf of the user.

Question

Hi, I'm in the middle of implementing a font manager, that works like a standard package manager with configurable repos etc.

I'm here to ask the official stance on how these kind of use-cases should be handled according to the Windows platform convention.

Firstly there's the KnownFolder API which has ID:s for the system-level font folder which is not modifiable without administrator access and affects the whole machine, which is not exactly desireable.
But sometime during 2018 Windows introduced the user-specific font folder at %userprofile%\AppData\Local\Microsoft\Windows\Fonts. Oddly, this folder was NOT added to the KnownFolder API and exists in a weird limbo that there isn't any specific documentation saying if I should or should not access and modify that folder in behalf of the user.

This issue has already been hashed through on StackOverflow: Why was the user font directory not added to the KnownFolder API? (Question originally originated from this Dirs-rs issue #37 discussion and I accidentally rehashed it at the higher level Rust crate Directories-rs issue #75 ), but this was not a direct answer from Microsoft and the delivered answer was largely just derived from this Microsoft Devblog, The Old New Thing: "Why is there no programmatic access to the Start menu pin list?" from 2003.

With the assumption that all the above is correct and I shouldn't be accessing that folder in behalf of the user, then is the implementation that I've come up with the "most optimal" and "correct" way of handling it?
I have to initialize a service/daemon that upon login registers a knownfolder for the font manager fonts (This isn't strictly necessary, but seems to be beneficial for Enterprise use-cases), then registers all the managed fonts via AddFontResourceExW and sends a window broadcast to update the font tables after all the managed fonts are registered.
This seems to be the way Windows api tries to push you, but I'm not a fan of adding any more processes to slow the login process, but I guess that is the price you pay for abstraction.
Aside, performance note: registration could take a considerable amount of time, so just adding the fonts to the user-specific font folder seems quite beneficial that you could offload all that hard lifting to the OS.

Any input, extra documentation and/or a official guidance on the matter would be highly appreciated!

This'll squash some issues on a few public repositories for different languages that implement cross platform, user/system folder APIs, so thank you in advance :)