The analysis makes sense, I don't understand why this is the correct fix.

Colours aren't the only thing lookandfeel syncs to kdeglobals when set.
Is it correct that all of them have a fallback to loading a second config? If they do, why does the lnf kcm copy into kdeglobals instead of just deleting the kdeglobals entries?

Or the QPA could look at the LnF in the first place instead of kdeglobals?

In D20205#442466, @davidedmundson wrote:

The analysis makes sense, I don't understand why this is the correct fix.

Colours aren't the only thing lookandfeel syncs to kdeglobals when set.
Is it correct that all of them have a fallback to loading a second config? If they do, why does the lnf kcm copy into kdeglobals instead of just deleting the kdeglobals entries?

as far i know, kcolorscheme only looks for colors in kdeglobals (more precisely, reads from KSharedConfig::openConfig(), which is from applicationnamerc and then falls back to kdeglobals)

an alternative approach could also be making kcolorscheme directly read from lnf, tough, may add complexity is a more often used code path?

the fallback is:

• colors in applicationnamerc
• colors in kdeglobals
• colors from the colorscheme file set as ColorScheme again in kdeglobals
• look in the lnf package set in kdeglobals, then look if it contains a "colors" file
• look in the lnf package set in kdeglobals, then look at the "defaults" file in the lnf, and look at the color scheme name

Is probably better to do this dance only once at startup?