I know this must seem like a huge backward step -- Bill and everyone else is going to be shaking their heads and going: "Hey, we've gone OVER all this already!!" -- but for those of us (might just be me, actually) who are (unfortunately still) node dummies and who are a bit thick besides, a bit of review.

Come to think of it, critical review. I wouldn't have said what I said in that earlier post about not understanding how plugging a maths add node that added 0 to 0 (resulting in 0) would send "do nothing" to the renderer if this concept were firmly entrenched.

"Plug into a channel" is the same as "multiplication".
So:
plugging any output with a value of 0 into an input channel is going to be multiplying the value in that input channel by 0.

So, adding colours (since that's something I'm wanting to do) needs to be done in a color_Math Add node... then you can plug the result into a blender and then into your GC thingie... no wait. You should GC your colours first.

Right.
Then, add (or whatever you want to do with) those colours.
Thus:

What this is saying is:
Up the value of each colour in the Value_1 channel by the power of (the value_2 channel * 2.2 = 2.2)
Add colour (Value_1 * the output of color_math) to colour (Value_2 * the output of color_math_2)

The clamp - not sure if I'm using it properly - is to prevent making a hyper-colour. I find it interesting that the colour doesn't look any different in the "clamp" output screen... Poser must already do some sort of clamping because it can't display a hyper-colour, which is definitely what this would have been:
(.619 , 0 , .494) + (1 , .235 , .153) = (1.619 , .235 , .647)

So, question. What is clamp doing? Looking at each element of the tuple and deciding which one needs to be kept from going over the limit? Well, no. Tried that. Didn't give me that colour above:
1.619 chopped down to 1 -> 255
.235 -> 60
.647 -> 165

So, I did something that taxed not only my maths abilities to the stretching point, but those of the rest of the household: I decided I'd determine what percent of 1.619 1.000 was, and reduce the other colour values by the same percentage (61.7665). So:
61.7665 percent of 1.619 = 1 (roughly) or 255
61.7665 percent of .235 = .145 or (roughly) 37
61.7665 percent of .647 = ..3996 or (roughly) 101

I think it's safe to assume that "clamp" is going to be doing far more accurate maths than I am - heck, anyone in the solar system is going to be doing more accurate maths than I do - so that might account for the slight difference in colour.

Something this little exercise has brought to light: the colour from the colour picker is not the same as the colour in the preview window after the exponential maths have been applied. Which makes me want to revise my shader a bit - I'm not displaying that preview window on those color_math pow nodes where users will potentially be selecting colours for makeup.... hmmmmm.

Adding colours and invoking "clamp" is not the same as blending them:

Needs to be noted this is just a first part of the colour process .... gamma (back to sRGB) isn't displayed here.

Monterey/Mint21.x/Win10 - Blender3.x - PP11.3(cm) - Musescore3.6.2

Wir sind gewohnt, daß die Menschen verhöhnen was sie nicht verstehen
[it is clear that humans have contempt for that which they do not understand] 

Metaphor of Chooks