Thank you for the feedback! I have a lot of reading to do on LCH, which does seem very nice. The only issue I see is that it might not satisfy my (perhaps irrational) preference for having a channel for “tints/shades”, totally independent of the channel for “chroma”(tones). That is, with HCY (or HSL) I can use the Y channel to go from 100% black to 100% white, regardless of the Chroma channel. This is really useful. When the MyPaint hotkeys were HSV, it was really annoying to crank up the Value and get “stuck” and then have to decrease the saturation to finally reach “white”. LCH appears to have this same behavior. HSL can go from black to white with the L channel, but the saturation channel doesn’t create “tones”, where tones is roughly defined as maintaining luminosity while decreasing chroma. LCH appears to be similar to HCY (probably a lot better) in its ability to keep the luminosity similar when changing the chroma.
Could it be possible to have hue and chroma step changes use LCH, but Luma step changes use HCY (or HSL)? I don’t see why not. Maybe mix and match would make sense. If you haven’t noticed I’m more than a bit suspicious of using a wheel/GUI at all for picking colors. Ultimately I would like to go “Full Screen” without an interface and just nudge the color one way or the other until it “looks right”. 
Too many Bruces involved in color! Your article was interesting, but I’m having trouble applying it to the idea of a severely limited palette, since I would almost never reach across the color wheel for the complements but instead reach across the limited gamut towards “subjective primaries” as James Gurney calls them. Here’s an example of a digital painting I did and the “gamut mask” I used, although this image represents the colors within an ~Adobe RGB colorspace, which is why it is such a small slice:
Yes, I’m using an Adobe RGB monitor with MyPaint and then going back and assigning my display profile and converting my image to sRGB. Yes, it is a nightmare. So what I’d like (I think) is a way to specify my light source color, say, yellow. Then I pick a red color and I want to make it “cooler” in relation to this light source. I think this paragraph from MacEvoy hints at the solution:
How do I make a color warmer or cooler? The answer depends on whether your axis of reference is the illumination or the hue circle. If you want to make a color warmer within a certain kind of illumination (that is, the light in any representational landscape or portrait), then the “warmest” color is typically shifted from red orange toward the color of the illumination. Greenish light makes oranges and yellow warmest, because reds are dulled almost to blacks; orange light makes oranges warmest, and dulls magentas and yellow greens.
So maybe even a 2D painting program needs a way to configure the “light source” color, maybe defaulting to D65 or D50? Then we can shift hue and chroma in relation to that in a logical fashion. . . However, there can be multiple light sources in the scene, so maybe a solution would be to make swatches of your light sources either in the image or to the side. Then, with a brush color already selected you could hover your mouse over the swatch of your light source, and press the “warmer/cooler” buttons to make the adjustments. Obviously you could also do this with any other colors in the picture but it wouldn’t be “representational” but would still be useful. Hmm, it would be tedious to keep reaching for that swatch to make the adjustment… so maybe a global setting makes sense, but have a specific key shortcut that “captures light source color” so you can still change your light source color very quickly. Yes, I’m aware that I am rambling
Oh, I forgot to mention I added some neat color channel pickers that sample a particular channel. Right now H, C, or Y only but I could imagine setting a preference for other spaces, even RGB. Here’s a little demo:
It can be pretty useful for picking a hue from palette, wheel, or another part of the painting and then force it to match your existing color scheme with the constrained C and Y channels.
Actually, I think the GUI and these wheels is one of the areas we can really afford to use more CPU, if needed. The only performance-critical thing is the actual laying of strokes, IMO. Don’t lag the brush!
Can you explain that a bit more? I thought as long as it was “three lights” the same concepts apply, whether it is Adobe RGB, Rec 709, etc etc.
Great question. I noticed that too and switched them out for Rec 709 numbers but didn’t notice a big difference, and I learned none of those coefficients should be hardcoded anyway :-P. So, add that to the list of not-quite-right stuff to fix. Actually, I believe there are some references to W3C standards, and the actual standards for certain things specify those particular coefficients, even though that doesn’t seem to make any sense