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

Goal: Understand how the CSS @property rule should behave when a later declaration re‑defines the same custom property with a different syntax value, particularly whether the property’s value must be reset to its initial value to avoid duplicated writes in animation worklets.

Uncertainty: The current specification does not define the interaction between cascade layers, !important, and redeclaration of @property, leading to divergent implementations—Chrome enforces strict type checking at parse time, while Firefox permits fallback values without triggering invalidation. This inconsistency can cause duplicated or missed writes when the property is updated in worklets that rely on typed custom properties.

• Should a later @property rule with conflicting syntax reset the property to its initial value?
• How should cascade layers and !important influence the effective value of a redeclared custom property?
• What is the expected behavior for animation worklets when the property is updated after such a redeclaration?