SUMMARY This would hugely simplify a couple of problems with the current model: 1. The biggest one is that a couple of Plasma Styles only exist to force a different color scheme from the one used in Application Styles. 2. Breeze Dark and Breeze Light (both Plasma Styles) both exists for that only purpose. The only significant difference between them and the original is that they force the Breeze Dark/Light(Color Scheme) into Breeze (Plasma Style). They could be removed with my proposal. 3. It would help reduce basic maintenance. Currently, the Color file from Breeze Dark(Plasma Style) differs in one or two lines from the Breeze Dark Color Scheme, this doesn't appear to be intentional. Each time a Color Scheme is updated, KDE Devs need to remind themselves of also updating the color file inside those Plasma Styles variants. My proposal eliminates the need for that. 4. Every time some new feature is added to Color Schemes, dev time is lost trying to reimplement it in a way that plays nicely with Plasma Styles. The most recent example is the accent color feature, which is currently not working with Breeze Dark/Light, the required fix isn't merely updating the color file, but changing how Plasma Styles are updated. This (probably) wouldn't be the case if the user could just use the default Breeze (Plasma Style) and select manually select it's color scheme to be different from the one used in Application Style, as the default breeze (Plasma Style) plays nicely with the accent color feature. This could help simplify the implementation of a scheduled Dark and Light Mode for users that don't use breeze for either Color Scheme or Plasma Style 5. Users would be able to create more colorful variants of Plasma Styles by simply changing which color scheme it is using. They could even just edit the Color Scheme themselves, as KDE has a useful GUI tool for that integrated into System Settings. They can do this now, but they need to fork a Style and manually replace the Color file with the one they created, it also lacks visual feedback.
It's probably a good idea in general, but we have to remember out theming ecosystem. Right now Plasma themes can have embedded color schemes. We could make this change for Breeze, but 3rd-party Plasma themes could and would still have hardcoded colors. So we can't stop that support entirely, which means that the UI would have to diverge between themes that supported being recolored and themes which don't. ...Which we could do, but it's something that would have to be kept in mind. If I could go back and wave a magic wand, I'd redo theming to be like how you're proposing, but sadly no such magic wand exists. :)
>the UI would have to diverge between themes that supported being recolored and themes which don't. ... I don't really think that's a problem per se? I mean, first that is already the case, isn't it? Themes that follow the Color Scheme behave exactly like I say, and they have a Icon to indicate they follow the Color Scheme. In this case it would be the opposite, Styles that have a Color file would show a icon to indicate they were bundled with one. Second: Styles could still bundle color files with themselves, as it has a utility for third party styles, but the user could force it to be ignored. If I force Breeze Light (Style) to use the Breeze Dark (Scheme) it would accomplish the same as if I used Breeze(Style) with Breeze Dark(Scheme) rather than the light variant.