Registered and un-registered custom properties with relative units behave differently in the cascade. When a property is not registered, it will inherit before resolving (2em inherits as 2em and resolves based on the element where applied) – but a registered <length> property will resolve 2em into a pixel value that inherits. The value is not re-calculated at the point where the property is applied.

Both behaviors can be useful, and are becoming even more relevant as we think about the behavior of mixins and functions. Various articles have been written about how to 'capture' a value -- @kizu has covered both the existing and @function-based approaches, and links to several other relevant posts. The functional approach is even used in an example of custom mixins where authors want the units passed into a parameter to resolve once for a given call of the mixin.

@function --as-length(--arg <length>) { result: var(--arg); }

It seems to me that there's enough desire for this behavior, it probably should not rely on every project duplicating the same custom function. Maybe we need a built-in function (or functions) for this?

Maybe tangential, but…

• I believe there was also discussion of the style() function used in both if() and @container, with a proposal for something like style(--x as type(length) > --y). I can't find that conversation off-hand.
• There are also use-cases for 'type casting'. Length-to-number casting can be achieved in other ways like dividing-by-units (if browsers implement) or the new progress() function. But it's still difficult to take a number (for example) and cast it as a string that can be used for generated content.