A library publishes a closed set of subtypes in v1, downstream code matches exhaustively over it, and v2 adds one more member. What actually breaks, and how do languages differ in what they force the library author or the client to write?

## The change and its blast radius An exhaustive match is a compile-time proof about a set. Enlarging the set invalidates every such proof in the program -- including proofs compiled into artefacts you do not control. Two distinct compatibility questions follow, and candidates who conflate them give weak answers. **Source compatibility**: will client code still compile? For a sealed hierarchy with exhaustive matches, no. Every match that relied on totality now fails to compile. This is loud, guided and usually welcome -- the compiler hands you the work list. **Binary compatibility**: will an already-compiled client still run? Also no, but silently until it hits the new case. This is the dangerous half, because it only fails on the input that carries the new case, possibly in production, possibly months later. ## How each language handles it **Java (sealed classes, standard since 17).** The `permits` clause is a compile-time fact. Pattern-matching switches over a sealed type compile to a form that throws `MatchException` when nothing matches, so a stale client gets a run-time failure rather than a silently wrong branch -- better than a silent default, still a production incident. Java offers no `non_exhaustive` equivalent. Its levers are: do not seal a type whose case set may grow; keep the sealed type inside a module recompiled as a unit; or make the hierarchy `non-sealed` at the branch that must grow, which surrenders exhaustiveness there. **Kotlin.** Sealed classes and interfaces behave the same. A `when` used as an expression must be exhaustive, so the compiler catches the gap on recompilation; a stale client throws `NoWhenBranchMatchedException`. Since Kotlin 1.7 a `when` statement over a sealed subject also warns/errors on non-exhaustiveness, closing the older hole where a statement `when` silently did nothing. **Rust.** Rust anticipated the problem at the library level with `#[non_exhaustive]`. Applied to an enum, matches in *other* crates must include a wildcard arm; matches inside the defining crate stay exhaustive. The result is that adding a variant is a semver-compatible change. Applied to a struct, it prevents downstream literal construction so fields can be added later. The cost is real and permanent: every downstream match carries an arm that is unreachable today, and if the wildcard is written as a silent no-op, new cases are ignored rather than handled. **Swift.** Swift makes the same bargain but defaults the other way for libraries built with library evolution: a public enum is **non-frozen** unless annotated `@frozen`, so clients must write `@unknown default`. Crucially, `@unknown default` is not a plain wildcard -- the compiler still warns when the client is rebuilt against a version that has new cases, so the sites can be found and handled. That is the most refined design of the four: safe by default, with a rebuild-time nudge. **C#.** C# has no sealed discriminated unions as of C# 13, so teams emulate them with an abstract class and a private constructor. Switch expressions over such an emulation throw `SwitchExpressionException` when nothing matches -- the same run-time backstop, without any language support for evolving the set. ## The design decision The question is not "sealed or open" but **what promise you can keep for the lifetime of the API**. - Seal when the case set is fixed by something outside your control: a frozen wire format, opcode set, a mathematical shape such as success/failure, an AST for a language whose grammar is stable within a major version. - Do not seal, or use `#[non_exhaustive]`-style markers, when the set encodes business categories -- payment methods, notification channels, tenant tiers -- because those grow whenever the business does. - If you must add a case to a sealed public type, treat it as a major-version change and say so in the release notes. Recompilation is part of the upgrade, not an optional extra. ## Operational advice Three practical habits distinguish a senior answer: 1. **Keep the sealed type and its consumers in one release unit** where possible, so "source-breaking" is the whole story and binary staleness never arises. 2. **Never write a silent catch-all.** If the language forces a wildcard arm (Rust, Swift), make it fail loudly or log and degrade explicitly -- a wildcard that returns a default value converts a compile-time proof into a silent behaviour change. 3. **Separate the internal and published views.** Some codebases seal an internal representation for exhaustiveness and expose a deliberately open interface at the module boundary, so internal code gets the compiler's help while consumers get room to move. ## Interview shape Split source from binary compatibility, name one language with an explicit evolution marker and one without, and land on the framing that sealing is a versioning commitment made at publication time.