Neat idea!

If something like this was exposed (which I personally like, but I believe Ben is the decider on expanding the API) then personally I think it would make more sense to use signature overloading.

That could be:

color c;
c = hsb(h, s, b);
c = hsb(h, s, b, a);
c = rgb(r, g, b);
c = rgb(r, g, b, a);

...but honestly, for consistency with the API I would instead have expected it to be a five-argument form of color() that uses the existing RGB and HSB built-in keywords to indicate the mode:

color c;
c = color(r, g, b, a, RGB);
c = color(h, s, b, a, HSB);

You can't have a 4-argument form for color, as those signatures for taken, but it would be simple and clear, and not require four new function names with four new references pages et cetera.

It also might make sense to propose for Processing4 ....

Thanks for the comment, @jeremydouglass ! I thought about signature overloading (favoring hsb() over hsba()), and I agree that it's appealing. If @benfry agrees, I would be happy to edit the PR to incorporate that suggestion. (EDIT: I decided to go ahead and do this. d437bc6 has this overloaded API.)

I also strongly considered color(r, g, b, a, RGB), but I wanted a way to specify the color space without also specifying the alpha channel. For example, with the proposed API you can specify color c = rgb(100, 200, 250);, but overloading color() instead would require users to write color c = color(100, 200, 250, 255, RGB);, and that didn't seem as ergonomic to me. Again, I would happily yield to the judgement of @benfry and push an alternative that better fits the Processing project.