A published library's public API compatibility promise under Semantic Versioning covers more than just function signatures. Besides removing or renaming an exported function, name two other kinds of changes that count as 'breaking' under SemVer and explain why each breaks the promise even though no code was deleted.

## What 'breaking' actually means SemVer defines a breaking change **functionally, not syntactically**: it's any change after which code that correctly used the previous public API can behave differently or stop working, without that code itself changing. This definition is deliberately broader than 'did we delete or rename an exported symbol,' because most real breakage in production doesn't come from deletions — deletions are loud and show up as compile errors. The dangerous breaking changes are the quiet ones: the symbol is still there, the signature still type-checks, but the behavior underneath shifted. ## The categories that remove nothing Concretely, a handful of change categories count as breaking even though nothing was removed. - **Changing a default parameter value** means every caller who didn't explicitly pass that argument silently gets new behavior — their code compiles and runs, it just does something different. - **Tightening input validation** (rejecting a value that used to be silently accepted or coerced) turns previously-working calls into runtime errors. - **Changing the shape or type of a return value** — adding a required field to a response object, changing an enum's set of values, or changing error types thrown — breaks any caller that destructures, serializes, or pattern-matches on the old shape. - **Changing timing/ordering guarantees** (e.g., a function that used to run synchronously now returns a `Promise`, or a collection that used to iterate in insertion order now doesn't) breaks callers relying on that behavior even if it was never explicitly documented. - **Relaxing an invariant** a caller depended on can silently degrade correctness without any error at all. ## Why the promise is scoped this broadly The reason SemVer scopes the promise this broadly traces back to what the version number exists to guarantee: **safe, unattended upgrade**. If 'breaking' only meant deletions, a resolver could bump you across a change that compiles fine but silently corrupts data or throws in production — worse than a compile error, because it's discovered later and further from the change. By defining breakage behaviorally, SemVer forces maintainers to reason about their entire observable contract, not just their type signatures. ## Hyrum's Law This is where **Hyrum's Law** becomes central: 'with a sufficient number of users of an API, it does not matter what you promise in the contract - all observable behaviors of your system will be depended on by somebody.' Even things the maintainer never intended to promise — the exact wording of an error message, the iteration order of an unordered collection, undocumented side effects — become de facto API surface once enough consumers exist. A theoretically 'correct' bug fix that changes one of these can still break real users, which is why disciplined maintainers publish changelogs describing observable behavior changes, not just signature diffs. ## The trade-off The trade-off is between **API stability** and **the ability to fix design mistakes**. A library that treats every observable behavior as permanently frozen accumulates cruft and can't improve; a library that classifies changes too loosely as 'non-breaking' burns consumer trust and turns every upgrade into a gamble. Mature projects resolve this with an explicit, scoped public API definition — documenting what is and isn't covered by the compatibility promise (e.g., internal packages in Go modules, `@internal` tags, or a documented 'unstable APIs' list) — so changes outside that boundary don't require a MAJOR bump even if some user happened to depend on them. ## Failure modes Failure modes in production typically look like a support ticket or a CI failure after a routine dependency bump: an application's tests pass locally against the old dependency version, get upgraded automatically via a MINOR/PATCH range, and then either throw at runtime (validation tightened) or — worse — silently produce wrong output (default value or return shape changed) with no test catching it because the suite didn't cover that specific default. ## Where it shows up A concrete real-world example: Node.js's own core APIs are notoriously conservative about this exact issue — changing the default encoding of a stream, or making an implicit type coercion stricter, has historically been treated as a semver-major change specifically because of the sheer number of undocumented behavioral dependencies across the ecosystem, even when the 'fix' made the API more correct. Express.js and similar frameworks maintain explicit migration guides between major versions precisely because their 'breaking changes' lists routinely include default-value and validation changes, not just removed methods.