What makes a shared component's interface stable enough that consumers can upgrade without breakage?

The properties of a durable component interface

• A small, intentional surface. Every property is a commitment. Components with dozens of configuration properties cannot be changed, because some consumer depends on every combination.
• Composition over configuration. Slots and children let consumers vary the content without the component needing a property for each case — which is what keeps the surface small as requirements grow.
• Behaviour separated from appearance, so styling changes do not force interface changes and theming does not require new properties.
• Documented accessibility and interaction behaviour, since consumers depend on keyboard handling and focus management whether or not it is written down. Undocumented behaviour is still a contract, just an accidental one.
• Explicit versioning with a deprecation path: mark, warn in development, provide a migration, then remove.

The failure that recurs

A property added for one consumer's special case. It becomes part of the interface permanently, it interacts with every other property, and after enough of them the component is unmaintainable and every change risks a regression somewhere.

The discipline is to ask whether the request is a variation of the component or a different component — and to prefer composition, which lets the consumer solve their case without expanding the shared surface.

The signal that the contract has failed

Consumers reaching past the interface — overriding internal styles, depending on the DOM structure, patching behaviour. When that happens the internals have become the contract, and the component can no longer be refactored regardless of what its documented interface says.