Inconsistent computed values for @property when redeclared with different syntax in cascade layers

Answer first

No. The CSS Properties and Values API does not require a later @property rule with a conflicting syntax to reset the custom property to its initial value, and it does not define a portable interaction between cascade layers, !important and @property redeclaration. The effective registration is determined by cascade order of matching @property at-rules, but how an existing computed value is handled when the syntax changes is implementation-dependent. Changing the registration mid-lifecycle is not a stable pattern for animation worklets.

Confirmed facts

• @property is an at-rule that registers a typed custom property with syntax, initial-value and inherits. Registration is document scoped.
• The effective registration is the winning @property rule under normal cascade ordering for at-rules: layer order, origin and order of appearance. !important applies to declarations of the custom property, not to the @property registration itself.
• The spec defines syntax validation for a registered property, but does not fully specify how a later @property rule with a conflicting syntax should interact with an existing computed value, nor how cascade layers and !important are applied to the at-rule itself.

Likely explanation vs confirmed behavior

Likely explanation, not portable fact: implementations diverge on strictness.

• Chrome tends to enforce strict type checking at registration time. A value that no longer matches the new syntax is treated as invalid and often falls back to the initial-value for that registration.
• Firefox has historically been more permissive with fallback handling and may not invalidate immediately, which can surface as duplicated or missed writes in worklets that expect a typed value.

This divergence means you cannot rely on an automatic reset to initial value, nor on consistent invalidation of animations and worklets when syntax changes.

Scoped steps for this case

1. Keep syntax stable per property name per document scope. Do not redefine the same @property with a different syntax in the same document lifecycle, especially across cascade layers.
2. If a different type is needed, use a different custom property name. Changing registration mid-animation is not a supported stable pattern.
3. Isolate registrations by scope. If you must test layer interaction, create a minimal test with two @property rules for the same name in different cascade layers with different syntax, then read the computed value via getComputedStyle and CSS Typed OM to observe which registration wins in your target engines.
4. Trigger a style change and an animation worklet update after the second registration and inspect whether the worklet receives a typed value matching the new syntax or falls back to initial/invalid. Compare Chrome and Firefox current desktop builds.

Missing diagnostic detail that changes the recommendation: Are the two @property rules in the same document and same shadow root, and from the same origin? Scope and origin affect which registration is effective and whether a layer can override a previous registration.

Note: Spec ambiguity means assumptions about automatic reset to initial value are not portable. Test in target engines and treat any syntax change as a breaking registration change.