Subjects

A subject is a reader-facing compatibility pattern -- what a maintainer would actually search for -- rather than a projection of which detector owns the underlying ChangeKind (see topics, on each case's own meta table). A case may belong to more than one subject when the pattern genuinely applies twice. ← back to all examples

Subject	Cases	What it is
API design and hygiene anti-patterns	6	The change is technically compatible (or a correctly-labelled risk) but represents a design smell -- namespace pollution, an unnamed type in the public ABI, a polymorphic type with no virtual destructor, a deprecation announcement, or the experimental-API graduation/removal lifecycle.
Build-flag and toolchain-mode drift	12	The same source compiles differently because a build flag, language-mode switch, or standard-library ABI mode flipped between releases -- nothing in the source changed, but the generated code's ABI contract did.
Calling convention and integer-model changes	6	The generated calling convention, parameter-passing model, or a platform's integer/floating-point width for a type changes -- callers and callees stop agreeing on the machine-level contract even though no symbol name changed.
ELF export and linker metadata	10	SONAME, RPATH/RUNPATH, DT_NEEDED, symbol binding, or protected/default visibility metadata changes in the ELF dynamic section -- the loader's view of the library, not its symbol contract.
ELF security hardening and deployment risk	8	A binary-hardening flag, CPU-dispatch capability, or deployment/runtime-environment assumption weakens or shifts between releases -- usually still symbol-compatible, but a real operational risk.
Enum ABI and API changes	6	An enum's member set, value, name, or underlying-type width changes -- some breaks are ABI (value/size), some are source-only (rename).
Export/declaration mismatches	9	A single-release audit (no old/new comparison) finds the binary's export table and its own public headers disagreeing -- an accidental export, a private header leak, an unversioned export, or a declaration with no matching export and vice versa.
Exported variable and data-object changes	6	A global/exported variable's type, qualifiers, size, or TLS model changes -- the same class of change as a function signature break, but for data symbols rather than callable ones.
Function-signature and source-API changes	21	A function or method's parameter types, return type, qualifiers, access level, or overload set changes in a way that is a source-level (recompile-required) break more often than a binary one.
Inheritance layout and base subobjects	4	A base class gains a member, changes position among multiple bases, or loses the empty-base optimization -- the derived class's own subobject layout moves even though the derived class's own members are untouched.
Inline-function and ODR-boundary changes	4	A function moves across the inline/out-of-line boundary, or an inline accessor's body changes what it references -- symbols appear, disappear, or silently reference something else, all without an explicit ABI-breaking declaration.
Public API depends on an internal declaration	15	A public declaration's own contract secretly depends on a private/internal declaration -- reachable only through the L5 source-graph evidence tier, including how the detector reconciles a dependency that was merely renamed or moved rather than truly removed.
Leaked internal types	4	An internal/detail::-namespace type reaches the public ABI by inheritance, by-value embedding, or a shared vtable -- a layout change the author thought was private moves the public class's own size, offsets, or dispatch table.
Modern C/C++ standard-feature hazards	6	A newer C/C++ standard feature (_BitInt, _Atomic, char8_t, [[no_unique_address]], ABI tags, customization-point objects) has its own, less-familiar ABI implications when it changes.
Multi-library bundle topology	5	The break is between libraries in one multi-library release cohort (ADR-023) -- a SONAME skew, an intra-bundle dependency removed, a provider migrated, or a manifest instantiation drift -- not inside any single library's own diff.
Opaque types, typedefs, and contract identifiers	9	A typedef's underlying type, an opaque type's hidden field, a pimpl alias, or a stable numeric/macro identifier (a serialization tag, a public macro or header constant) changes -- the contract was the name staying stable, not any particular layout.
Removed types and classes	5	A whole type, class, or a renamed policy/typedef family is withdrawn from a public API -- coarser-grained than a single function or field removal, usually the retirement of a historical API surface.
Safe changes correctly not flagged	12	A change that looks superficially risky is correctly left un-flagged: an internal/private-header type changed under public-surface scoping, a preprocessor-conditional false positive reconciled, or a genuinely ABI-neutral qualifier change.
Struct and type layout changes	21	A struct, union, or opaque record's own size, field order, offsets, packing, alignment, or bitfield widths change -- the core "does the compiled layout still match" family.
Symbol versioning and kABI	10	A GNU symbol-version node, an inline namespace used for ABI versioning, or a Linux kernel module's kABI CRC/namespace changes -- the mechanisms libraries use to version their own ABI, and what breaks when those mechanisms themselves move.
Symbol visibility scoping	4	A symbol is visible in the binary's export table but was never part of the declared public/header contract -- an ELF-only export whose removal is still a break for whoever found and used it anyway.
Tag-dispatch and empty-class ABI	3	A tag or empty-class type used for compile-time dispatch or as a symbol-mangling landmark gains state, gets renamed, or gets replaced -- its whole ABI role was to be small/stable, so any change to it is disproportionate.
Template and generic-programming issues	7	A class or function template's instantiation set, default arguments, or constraints change in a way visible (or invisible) at the binary or header level -- including a shipped binary missing an instantiation the header still declares.
Textbook symbol add/remove	3	The minimal, no-frills case of an exported function appearing or disappearing -- the baseline every more specific removal/addition pattern in this catalog is a variation on.
Vtable and virtual dispatch changes	13	A change to a class's virtual-method set, order, or inheritance reshapes its vtable, VTT, or dispatch thunks -- silent misdispatch or a crash, not a link error.