This post is yet to be completed - I accidentally posted it prematurely.
As a matter of fact I did read the manual (“when all else fails …” 
)
For clarity: By “Snap! color system” I mean:
- the variety of supported color definition mechanisms: RGB (hex), (fair) HSL, (fair) HSV, X11/W3C, crayons, color numbers, and the Snap! color data type;
- Snap! primitive functions within the Pen palette;
- Snap! libraries: “Crayons”, as well as “Colors and crayons”.
Now for my remark on The Snap! color system being complicated.
I’m aware the subject of color is inherently complicated, as proven by the long history of color theories (Color theory - Wikipedia), and as hinted on in the Snap! reference manual (rainbow vs. the human eye; screen vs. print; transparency; etc.). This isn’t something anyone can repair. One could even argue that many well-intended attempts to systemize this subject have only made it more complicated, as evidenced by the multitude of color definition systems (RGB, HSL, etc.).
Clearly the Snap! team have attempted to provide a rich set of tools for color-savvy advanced users, while not scaring away the rest of us. In my view the team are struggling with this dual goal.
A naive user (which in many respects I am) may easily be confused by the treatment of color in the manual.
-
very few functions within the Colors and crayons library, or even primitives within the Pen palette, come with (adequate) Help texts.
E.g.
Help doesn’t mention no pen trail is left when the sprite is moved manually by the user. The meaning of RGBA (especially the A) in 
is not explained. Blocks such as 
, 
, 
, 
, and 
come without any Help at all. -
even though the color type (apparently a costume of 1x1 pixel) is supposed to be “first class”, it doesn’t have a tick box in the block editor’s long input name dialog, and I haven’t figured out yet how e.g. the coloured input boxes in functions like
actually work, such that I could “build my own blocks” featuring color type input.