No, we are not going to get sick of you! If I can't explain something properly it's my failing, not yours.

Back to basics....

If we are incorporating output gamma correction in our shaders (which we are), then:-

1. Any colour used within the shader on the basis of its appearance on screen (and that's how it should appear in the render) must be anti-gamma corrected on input. This applies to any colour channel.. diffuse, specular, ambient, translucent, reflection. It applies to a colour defined in a Simple_Color node, for example, just the same as it applies to colour maps.

(Your question about the weave node is a good one. Is it performing any internal colour maths? Would this maths give a different result if it used anti-GC'd versions of the selected colours? I don't know. But... someone presumably set up this weave node within the shader on the basis of how it appeared on their screen, either in the material room or in the render itself. So you could just anti-gamma correct the output of the weave node, and it will appear in your gamma-corrected render the same as you see it in the Material Room).

2. Any arithmetical operator expressed as an RGB fraction -- e.g. the (0.5,1,1) red-channel reducing multiplier I used as an example -- must not be anti-gamma corrected.

In my example, I wanted my RGB number to halve the intensity of the red channel in whatever light value is coming in from the scene, but not alter the green and blue channels. That's why I put 0.5 in the red channel, and 1.0 in the green and blue channels. It's already a linear-space number. If I were to anti-GC this number, it would change it to approx. (0.21,1,1), and when used as a multiplier it would reduce red channel intensity to less than a quarter of its original value.

"If I were a shadow, I know I wouldn't like to be half of what I should be."
Mr Otsuka, the old black tomcat in Kafka on the Shore (Haruki Murakami)