Reject conflicting runtime manifests for an already-owned root

Start at packages/runtime/src/core.ts:109 and trace the existing Rust schema/engine ownership boundary and binding codegen path. Review the startup, refresh, disposal, and failure-retry tests, then run focused Rust, binding, runtime, and browser coverage. Done means compatible contexts reuse safely, conflicts reject without mutation, and the documented acceptance matrix passes.

Decision and classification

Recommended for 2.0 · Intentional breaking public-contract change. Reject a conflicting manifest supplied to MasterCSSRuntime.start() for a root that already has an active or pending runtime. Reuse remains valid when the supplied manifest represents the same validated execution definition.

Parent: #445. Related: execution compatibility #450, rendering integration #451, documentation #453 and readiness #454.

This is not an implementation/documentation mismatch: the current README explicitly makes the first concurrent call authoritative. The change is proposed to prevent successful initialization against a different project context than the caller supplied. It does not introduce multi-manifest merging or a general semantic comparison API; the latter remains #459.

Baseline: 70444b18c8102fa7a9d811ec51ef96902573792c.

Current behavior and evidence

Two manifests define the same static box utility as red and blue respectively. On the same Document root:

const a = await MasterCSSRuntime.start({ manifest: redManifest })
a.observe()
const b = await MasterCSSRuntime.start({ manifest: blueManifest })
b.observe()
// a === b; .box remains red; the second manifest is silently ignored

Reversing the initialization order keeps blue. Concurrent starts also share the first caller's context. Both behaviors were observed in Chromium and WebKit on 2026-09-27; this new case has not been run in Firefox.

core.ts:109 returns an existing/pending runtime before validating or comparing the incoming manifest. README:133 documents first-caller authority.

Target contract

• One Document or ShadowRoot owns one runtime execution context.
• start() with the same validated execution definition reuses the active/pending runtime, including separate object instances and codec roundtrips. Object reference identity is insufficient.
• A different definition rejects that caller with stable RUNTIME_CONTEXT_CONFLICT diagnostics and guidance to use the owning integration's explicit refresh(manifest) or a separate root.
• Reject before registering incoming emitted-global counts or replacing hydration data. A conflicting caller must not mutate, cancel or dispose the valid active/pending runtime; concurrent compatible callers still succeed.
• Validate incompatible language/envelope versions instead of silently bypassing rejection when a root already exists.
• Only a successful explicit refresh(manifest) changes the accepted context. Failed refresh leaves both execution and identity unchanged. Disposal releases the root for a different context.
• Keep same-context emitted-global accumulation and the existing startup coordination contract. This issue does not redesign timeout/binding precedence, resource unloading, or multi-root isolation.

Implementation plan

1. Add a validated execution-definition comparison/identity operation at the existing Rust schema/engine ownership boundary. It must cover the complete effective definitions, including currently unused tokens/utilities/modes/variants and meaningful order. Do not compare only currently emitted CSS or a finite class sample.
2. Normalize according to established Rust contracts. Ignore opaque, non-executable envelope metadata and object member order only where the contract makes order immaterial. Preserve declaration/fallback order, definition precedence, namespace fallback and branch order. Do not blindly sort every JSON object or infer equality from current token values.
3. Expose only the minimal capability needed by the runtime through the existing engine/binding boundary. Do not depend on compiler/tooling from runtime, add a TypeScript semantic fallback, or require a public hash in the Manifest. If a digest is used as an optimization, retain collision-safe confirmation rather than treating the digest as proof.
4. Capture the accepted definition at startup without retaining mutable caller data as the authority. Check both active and in-flight startup paths before applying caller contributions. A rejected caller's diagnostic callback must receive its own conflict; compatible startup must not be poisoned.
5. Update the accepted identity atomically with successful refresh, and test cleanup/retry after startup failure and disposal.
6. Update runtime API documentation, framework initialization guidance and the v2 RC migration guide: repeated same-context startup is idempotent; context replacement is explicit. No new migration profile is required solely for this API change.

The baseline binding ABI is 13. If the minimal operation changes the binding contract, advance the then-current ABI and regenerate native/Wasm/TypeScript artifacts through existing codegen; do not hard-code an outdated next version during concurrent work. No Manifest/hydration wire change is intended. Document the exact resulting API/ABI impact in the implementation report.

Acceptance and validation

• Sequential and concurrent equal manifests reuse one runtime; red/blue conflicts fail in either arrival order without changing the winner's styles.
• Cover separate object instances, serialization/reload, permitted omitted defaults, opaque metadata and meaningful versus immaterial ordering.
• Differences in unused definitions are detected; identical current CSS is not evidence that contexts match.
• Invalid/unsupported versions are rejected on both fresh and already-owned roots.
• Conflicting calls cannot add emitted-global counts, replace hydration data, alter class tracking or destroy the active runtime.
• Successful/failed refresh, caller-object mutation, failed startup retry and dispose/restart preserve the contract.
• Separate ShadowRoots may use different contexts. Official integrations' duplicate initialization with the same project context remains valid.
• Run focused Rust normalization/identity tests if added, binding codegen/parity for changed contracts, engine/runtime tests, affected package lint/type-check/build and browser cases in all three supported engines.
• Measure first start, repeated compatible start, conflicting start, refresh and full runtime payload. Include large manifests; avoid adding a full engine initialization to every compatible repeated call without measuring and justifying it. Remeasure regressions above 5% and record attribution.

Sequencing and exclusions

Dependencies: #462 and #463. Implement after their CSSOM and nonce/failure-atomicity fixes have landed, or rebase before touching their shared startup/hydration paths. Reuse their scoped tests and perform one final combined rendering matrix under #451. Feed compatibility evidence to #450 and update the readiness assessment in #454.

Do not reopen completed utility syntax, sizing removal, Next HMR, Svelte delivery, project-definition sharing, or #457–#460 authoring work. No implicit manifest merging, new CSS DSL, publication, CI or lockfile changes are included.