A lot depends on typed on typedness. If breaking changes are identified during compilation then the cost of minor breakage somewhere is low. The quantity of cha

A lot depends on typed on typedness. If breaking changes are identified during compilation then the cost of minor breakage somewhere is low. The quantity of change is far more interesting than strict absence/presence. And it takes so little change to get unexpected client code broken that I'm very sceptical of attempts to prevent it in API design. Take classic java for example. If you have a public interface adding a method can break someone's client code because nothing can keep them from implementing that interface and the implementing class might already have a method with a colliding interface. If you went completely over the top with compatibility expectations you could even argue that it's impossible (pre-modules I think?) to add any class or interface at all because someone at foo.com might have rudely put a client code class with the same name in your precious org.bar namespace. Nothing in the language prevents that. Trying to design out the possibility of breakage isn't worth it, you'll end up with conventions that soften the definition of "breaking change" anyways (or with the antipattern of major-only increments)