Currently MoonZoon has two built in color concepts: the HSLuv color space and a palette. Integrating them is convenient, as framework users do not need to think about colors much. They can just use them.

For anything but technology demonstrations, application developers will want to use a palette that matches their corporate identity and expresses their visual design goals, though. A predefined palette is just dead weight to them. Luckily it can just be ignored, by not importing the named_color module.

A built in color space and color space library is more problematic. Just like built in colors, it biases framework users toward using it. However it also is part of function signatures. So framework users that prefer a different color space need to actively work around it.

I think I remember reading somewhere that @MartinKavik was very pleased to have found HSLuv, because it seemed like a panacea to all color-related problems. However it is not and there can not be one. You have to make a trade off between a number of design goals.

Personally, I will be using the OKLab color space -- see the comparison to HSLuv -- which has also been integrated into the Unity game engine and seems to be finding its way into the next CSS Color specification. I with be using it via the palette crate, which does not have a stable API yet, and a number of open issues, but seems focused, well designed and very actively developed.

So my preference would be for MoonZoon to be color-neutral and make it easy for users to use their color space and color library of choice.