I feel like this is missing an important bit of context, at least it's not obviously part of this discussion though I expect it's known somewhere. Keeping thin

I feel like this is missing an important bit of context, at least it's not obviously part of this discussion though I expect it's known somewhere. Keeping things compatible is essentially always preferable. Making breaking changes is in isolation a bad thing but can be worth it for what you get out of it. Is there a wishlist of "if only we could break compatibility, we'd do X/Y/Z"? > The specifications that have been published to date provide no stability guarantees, but we will be adding explicit guarantees with the next publication. However, it seems disingenuous to promise "no breaking changes" while including breaking changes. Not really, this seems pretty par for the course of any project hitting a 1.0 release - announcing that things are now stable. Perhaps that's a better framing, you wouldn't release something saying no breaking changes while containing breaking changes, but releasing something that has breaking changes as a stable thing makes a lot of sense.