In #10577 we just resolved to add a color-scheme() test to if(). This is trivially cyclic if used in the 'color-scheme' property, of course.

We already have a way of reliably detecting and dealing with cycles in if() tests - we track dependencies as we resolve substitution functions, and when a cycle is detected, the thing triggering the cycle substitutes as a guaranteed-invalid value instead.

But we also have a precedent for dealing with cycles caused by using property-dependent values in those properties: an 'em' used in 'font-size' resolves based on the parent font-size instead. If applied here, this would allow the behavior of having an element use the opposite color-scheme of its parent.

I'm inclined to keep to the existing precedent that if() (and other substitution functions) use, where a cycle is simply invalid. An if() that queries the --foo property in the --foo property doesn't look at the parent's --foo, it just fails, and I think consistency in this manner is more important.

The behavior of using the opposite color scheme to your parent can be achieved using a CQ, since we also resolved to add a color-scheme() test to CQs. (I also think this isn't an important use-case to worry about. Pages virtually always want to use consistent color schemes; the point of the color-scheme() test is to let you easily do inline branching a la light-dark(), but for arbitrary values. If it's possible to invert your parent's color scheme, great, but if it's not possible (without JS or something) I think it's perfectly fine.)