Historically (and per-spec for RGB colors - "For all other sRGB values, the declared, computed and used value is the corresponding sRGB value.") color values have serialized the same way for declared and computed values (with the exception of "CSS named color, a system color, a deprecated-color, or transparent."

One unfortunate side effect of this is that calc() values get lost, in a way that is distinct from pretty much all other declared values (or at least in my limited testing). For instance, color: hsl(calc(30 + 60) 50% 50%) serializes as rgb(128, 191, 64), where as width: calc(20px) serializes as calc(20px). While there may be a compatibility reason to continue doing this for the RGB/HSL/HWB set, what is the argument to continue that on for lab()/lch()/oklab()/oklch()/color()?

Relative colors kick the trend, and are, I think, spec'd to serialize their declared form as declared (presumably retaining calc(), though that is not explicitly stated). I can't quite work out if that is the intention of section 11.2. Serializing Relative Color Functions, as there is some text that reads:

The serialization of the result of a relative color function depends on whether the keyword currentColor is the origin color.

It's not clear to me when this condition should kick in.

What is the rationale for using the computed value serialization for all absolute color serializations?
What is the intention of relative color serialization section? Is the intention to serialize declared values as declared, or only when currentColor is used?