The color change-inducing-friction complaint seems like an issue with lack of built-in theme sanity checking. There exist numerous partial solutions for this already, I'll link to the four best ones I know, albeit I wish someone would combine their approaches into one unified super-product:
1. http://www.hsluv.org/examples/ These palettes will absolutely NEVER clash. But they might have contrast issues. Which brings us to:
2. https://news.ycombinator.com/item?id=19800718 Lyft primarily designed ColorBox.io to always reach WCAG 2.0 contrast ratios. Something I'd claim a ton of UX themes mess up. Unfortunately from what I can tell, it lacks the anti-clash guarantees of #1
3. Much less related, but still important, albeit only for very specific parts of any UX:
But, unfortunately, it too only serves as a partial solution (since, as far as I know—someone please correct me if I got that wrong—it doesn't address any of the matters discussed above), PLUS it seems highly likely that Adobe has software patents on it.
1. http://www.hsluv.org/examples/ These palettes will absolutely NEVER clash. But they might have contrast issues. Which brings us to:
2. https://news.ycombinator.com/item?id=19800718 Lyft primarily designed ColorBox.io to always reach WCAG 2.0 contrast ratios. Something I'd claim a ton of UX themes mess up. Unfortunately from what I can tell, it lacks the anti-clash guarantees of #1
3. Much less related, but still important, albeit only for very specific parts of any UX:
The color map generation approach in Matplotlib: https://www.youtube.com/watch?v=xAoljeRJ3lU (btw.: Seaborn, as mentioned in #1, builds on top of Matplotlib.)
For even more color madness, see this recent Hacker News comment by me as well as the other comments linked to there:
https://news.ycombinator.com/item?id=19983604