Evolvability
Change amplification, local reasoning and encapsulation radius — the properties that decide whether the tenth change is as cheap as the first.
A system is evolvable when the changes it is actually likely to receive stay local and understandable. The word "likely" carries the entire claim.
One requirement changes; count the modules, interfaces, tests and deployments that must move with it. Lower is usually better, and not always.
Pick an implementation decision and ask who has to be told when it changes. The set of modules that notice is the radius, and a smaller one is stronger hiding.
Extensibility is cheap along one axis and expensive along every other, so the only real question is which variation you have actually observed.
A plugin system is right when independent parties genuinely must extend you. What it costs — a frozen API, a lifecycle, isolation and compatibility — is permanent.
Something many modules depend on is expensive to change. Point dependencies toward the things that change least — and treat every stability metric as a hint, never a measurement.
Machinery built for a variation that never arrived: one implementation behind an interface, a plugin system with no plugins, an event bus for a local call.