You maintain a public library. A consumer added an extension function `User.fullName()` years ago. Now you want to add a member `fun fullName()` to `User`. What happens to the consumer's code, and how do you reason about the compatibility impact?

## The scenario A consumer wrote, in their codebase: ```kotlin fun User.fullName() = "$firstName $lastName" user.fullName() // calls the extension today ``` You now add to the library: ```kotlin class User(/* ... */) { fun fullName() = "$lastName, $firstName" // new member, same signature } ``` ## What happens at the call site By the **member-wins** rule, after the consumer **recompiles** against the new library version, `user.fullName()` resolves to the **member**. Their extension is now **shadowed** (the IDE flags it). The code **still compiles** — so it's **source-compatible** — but the **behavior changes** if the member returns something different (here, name order flips). That's a **silent behavioral break**. ## Source vs. binary compatibility - **Source compatibility:** preserved — no compile error; callers don't need code edits. - **Behavioral compatibility:** **not** guaranteed — the member may compute a different value. - **Binary nuance:** an extension compiles to a static synthetic method; a member is an instance method. Already-compiled call sites that bound to the extension's synthetic method keep calling it until recompiled. After recompilation they bind to the member. So the change manifests on **recompile**, not necessarily for stale binaries. ## Why this is the *safe* direction by design Kotlin deliberately makes **adding a member** the safe evolution step: because members deterministically win, a library can introduce behavior that callers transparently adopt, instead of extensions silently overriding the library. The dangerous direction is the opposite — depending on an **extension to override** a class you don't own, which the language forbids precisely to prevent hijacking. ## How to manage the change responsibly - **Match semantics** of the common community extension if one is widespread, to minimize behavioral surprise. - If semantics must differ, **choose a different name** so consumer extensions aren't captured. - **Document** in release notes; consider `@Deprecated` on a transitional API or a `ReplaceWith` hint where applicable. - Treat it as a **minor-but-behavioral** change in semver reasoning and call it out. - Encourage consumers not to rely on extensions to substitute for missing members of types they don't own. ## Mental model Think of the public type's member surface as the **authoritative contract**. Extensions are convenience sugar layered on top by callers; the language guarantees the contract owner wins, so evolving the contract is predictable — but predictability is not the same as behavioral transparency, which is the maintainer's job to communicate.