Component Library Versioning
Treating a design system as a versioned product with a compatibility policy and a deprecation process, because its consumers cannot all upgrade at once.
A design system consumed by fifteen applications is an internal library with fifteen consumers on fifteen schedules. Publishing a change to the main branch and expecting everyone to be current is the same mistake as breaking a shared API, and it produces the same outcome: consumers pin an old version and stop upgrading, after which the design system is a set of frozen copies.
What a versioning policy has to state: which changes are breaking (a removed prop, a changed default, a structural change that breaks consumer overrides), what notice a breaking change carries, and how long a major version is supported.
The subtlety specific to design systems is that visual changes are breaking too. Altering spacing, a colour token or a component's height can break a consumer's layout in a way no type system catches. Visual regression testing across consuming applications is the equivalent of a contract test, and without it a "minor" release ships a broken page.
The related discipline is limiting the override surface. A component that consumers customise through arbitrary style injection cannot be changed at all, because every internal detail has become part of the contract.