Design a component API that won't need a breaking change in six months

You are designing the public prop API for a design-system component, before implementation. The goal is an API that covers the real use cases below without a boolean-prop explosion, and without a breaking change the moment the next legitimate use case shows up.

COMPONENT NAME
Banner

USE CASES
1) An info banner at the top of a page. 2) A dismissible warning banner inline in a form. 3) An error banner with a retry action. 4) A success confirmation that auto-dismisses after a few seconds.

CONSTRAINTS
Must not depend on a specific styling library beyond CSS variables already defined in the design tokens; must work inside a form without stealing focus; must support RTL layouts.

EXISTING SIMILAR COMPONENTS
A separate Toast component already handles transient, corner-positioned notifications — Banner is only for inline, in-flow content.

API DESIGN RULES
Start from the use cases, not from a guess at every possible variant someone might want someday. Every prop you propose must trace back to at least one listed use case; if you cannot name which use case a prop serves, drop the prop. Prefer composition slots — children, a named slot prop, an asChild-style pattern — over a boolean prop per visual variant. If you are about to propose a fourth boolean like isCompact, isCentered, or isBordered on the same component, stop and ask whether a variant prop with a closed set of string values, or a composition slot, actually fits better; three or more independent booleans on one component is the concrete signal that the API has stopped being designed and started being accreted. Every prop needs a default that makes the component usable with zero configuration for the single most common use case in the list. Name props for what they mean to the person using the component, not for the CSS or implementation detail behind them — status, not colorScheme, when the actual intent being expressed is semantic, not decorative. Explicitly list what this component will deliberately not support — the use cases you are choosing not to design for right now — so that scope creep in a future review has something concrete to push against instead of an unstated assumption. Where the component wraps or extends a native HTML element, do not repurpose a native attribute name for a different meaning than it has natively — a prop called disabled should behave like the native disabled attribute a consumer already knows, not toggle some unrelated visual state, since reusing a familiar name for a different contract is a worse trap than inventing an unfamiliar one. Decide upfront, and state explicitly, which native HTML attributes and event handlers pass through untouched to the underlying element versus which ones this component intercepts or overrides — a consumer reaching for a standard prop like onClick or aria-label needs to know, without reading the implementation, whether it will reach the DOM node directly or get intercepted by internal logic first.

OUTPUT FORMAT
1. The prop table: name, type, default, and which specific use case it serves.
2. A short usage example for the three most common use cases from the list, as real code.
3. The explicit out-of-scope list, with one line on why each item was deliberately excluded rather than just forgotten.