The bug was found with:

ROSA Desktop Fresh R9 (2016.1)
Qt 5.9.1
KF 5.38.0
Plasma 5.10.5

There's a chance that it's KF5 bug and Breeze only triggers it.

Hi,
Thanks for reporting 
However this how it works:
When you select a color theme, its colors gets copied into kdeglobals. 
The decoration then follows that. 
If you alter kdeglobals, you then alter the colors seen by the decoration.
So what you report is the normal behavior. 
Closing as invalid.

(In reply to Hugo Pereira Da Costa from comment #2)
> Hi,
> Thanks for reporting 
> However this how it works:
> When you select a color theme, its colors gets copied into kdeglobals. 
> The decoration then follows that. 
> If you alter kdeglobals, you then alter the colors seen by the decoration.
> So what you report is the normal behavior. 
> Closing as invalid.

It's not really invalid because it seems to happen when there are no colors defined (copied) in kdeglobals.

See how it's done in plasma-integration: https://cgit.kde.org/plasma-integration.git/tree/src/platformtheme/khintssettings.cpp#n368

---
if (mKdeGlobals->hasGroup("Colors:View")) {
    m_palettes[QPlatformTheme::SystemPalette] = new QPalette(KColorScheme::createApplicationPalette(mKdeGlobals));
} else {
[load color scheme]
---

But Breeze decorator seems to ignore color scheme. Maybe it's because there are no [WM] color options in KColorScheme: https://cgit.kde.org/kconfigwidgets.git/tree/src/kcolorscheme.cpp

So KColorScheme::createApplicationPalette loads incomplete palette.

In fact, I don't know KDE internals well enough, so I can only grep sources and guess. Maybe [WM] colors are not designed to be set from KColorScheme. But somehow they should be loaded from color scheme (as they are defined there) if not defined in kdeglobals.

One more piece of code that loads [WM] only from kdeglobals and not from color scheme:
https://cgit.kde.org/plasma-desktop.git/tree/kcms/krdb/krdb.cpp#n137

Hi, 

you are right that my closing the bug was a bit hasty. Sorry about that, reopening.

I'll investigate a bit. But this is not breeze specific. 
Colors are dealt with by upstream libkdecoration.
Most likely it indeed does not look for the relevant default when the entry is missing from kdeglobals, and does not use kcolorshceme.

So, investigating: 
Colors are set in kwin/decorations/decoration
There, kconfiggroup is used, getting the WM colors from kdeglobals and if not found they are replaced by some entries in QPalette. 

Now QPalette itself has no role for window decoration, so the default are approximate. and in any case the color scheme "file" is ignored. 
But again, this is on purpose: setting the color scheme is simply (and nothing more than), copying the content of this file in kde globals. once this operation is done, no-one else knows about the original file, nor can access it. 

In any case, this is an issue to be dealt with at the kwin level, not breeze, sorry.

Surely, not a Breeze bug. 

And it looks like only [WM] from ~/.config/kdeglobals is loaded. Even [WM] colors from /etc/xdg/kdeglobals are ignored, not only from color scheme.

(In reply to Pulfer from comment #7)
> And it looks like only [WM] from ~/.config/kdeglobals is loaded. Even [WM]
> colors from /etc/xdg/kdeglobals are ignored, not only from color scheme.

Given the code this is intended. It explicitly does not ask for cascading config.

KWin itself does not have any idea about which color scheme is used and KWin certainly does not care about it. This does not belong into KWin.

This is something startkde or kcminit needs to take care of to make sure the color scheme is synced to kdeglobals.

Actually this bug should be reassigned to a component "plasma-workspace" or "startkde" but those do not exist, so reassigning to plasmashell as it's the most closest thing to the overall desktop.

(In reply to Martin Flöser from comment #8)
> (In reply to Pulfer from comment #7)
> > And it looks like only [WM] from ~/.config/kdeglobals is loaded. Even [WM]
> > colors from /etc/xdg/kdeglobals are ignored, not only from color scheme.
> 
> Given the code this is intended. It explicitly does not ask for cascading
> config.

Maybe there should be an exception for kdeglobals (as there are other hacks for kdeglobals in the code)?

-    auto config = KSharedConfig::openConfig(m_colorScheme, KConfig::SimpleConfig);
+    KConfig::OpenFlags openMode = KConfig::SimpleConfig;
+    if (m_colorScheme.endsWith(QStringLiteral("/kdeglobals")))
+        openMode = KConfig::FullConfig;
+
+    auto config = KSharedConfig::openConfig(m_colorScheme, openMode);

(In reply to Pulfer from comment #9)
> (In reply to Martin Flöser from comment #8)
> > (In reply to Pulfer from comment #7)
> > > And it looks like only [WM] from ~/.config/kdeglobals is loaded. Even [WM]
> > > colors from /etc/xdg/kdeglobals are ignored, not only from color scheme.
> > 
> > Given the code this is intended. It explicitly does not ask for cascading
> > config.
> 
> Maybe there should be an exception for kdeglobals (as there are other hacks
> for kdeglobals in the code)?

As I wrote: this is intended here, so no: this should not use a special case for kdeglobals.

Otherwise let's please keep this bug focused on the default config not having the WM group

Still it's quite surprising and unexpected behavior (of overall desktop) that most colors can be properly loaded from color scheme (with "~/.config/kdeglobals -> /etc/xdg/kdeglobals -> color scheme" priority order). While [WM] colors can be loaded only from ~/.config/kdeglobals.

KWin decoration colors are indeed unrelated to KColorScheme colors. The systemsettings color editor copies the colors of the selected scheme into the appropiate sections of 'kdeglobals'.

If the [WM] section (with decoration colors) is not present in the 'kdeglobals' file, KConfig falls back to try the application configuration file, in this case 'kwinrc'.

I do not see how it is a bug.

(In reply to Martin Flöser from comment #8)
> This is something startkde or kcminit needs to take care of to make sure the
> color scheme is synced to kdeglobals.

Can someone with good knowledge of Plasma internals implement this feature?

This would seem to be the cause of a downstream issue in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1963709

See also https://phabricator.kde.org/T13663

This was just fixed by Marco Martin in https://invent.kde.org/plasma/plasma-workspace/-/commit/590e0c0708febb9de4f88f4127e0f26fba6a9f70!