Moult keeps the old plugin generation serving until the replacement's setup returns

The bug the post prints is a single line, and the timing inside it matters: `registry.set('storage', await next.setup())`, carrying the comment that the old plugin is already gone before the new one exists ^[1]. `set` is called only after the await settles, so a throw inside `setup` skips the assignment, and an already-empty slot has to come from a teardown that ran earlier ^[27]. The state the protocol exists to survive is the same either way. The host is missing a capability it had a millisecond ago, and the post's line on that is "In a daemon, that's an outage, not an error." ^[2]

In Moult a plugin is a versioned capability provider with an owned resource scope, and a replacement runs four steps ^[4]:

1. `setup` runs in a private scope while the old generation keeps serving ^[5]. 2. Verify checks the candidate's provides and conflicts, and staged capabilities stay invisible to observers until commit ^[6]. 3. Commit swaps the active generation in one atomic step ^[7]. 4. Dispose tears down the old generation, releasing resources in reverse acquisition order ^[8].

Fail anywhere before the commit and the candidate scope is disposed, with the previous generation still active and usable ^[9]. The post's summary: "Like a crab, the system only sheds its shell once the new one is ready." ^[10]

A v2 whose `setup` throws comes back as a structured `MoltError` with the code `REPLACEMENT_FAILED` ^[11]. A consumer installed after that failure, requiring storage at `^1.0.0`, still binds v1's value ^[12]. Resolution runs during preparation, so a candidate whose requirements do not resolve fails before `setup` ever runs ^[15].

The transaction is not free. The published scenario is one install, one failed replace, and one hundred successful replaces, averaging about 16 ms for Moult against about 0.14 ms for the naive registry ^[21]. That is roughly 114 times the naive cost for the whole scenario ^[25], and about 0.16 ms spread across the 101 replaces ^[26]. Both figures describe setups that do almost nothing: the example's v1 builds a `Map` with one entry and hands back a `get` over it ^[13]. For a fraction of a millisecond per replace to mean anything in your host, the setups you replace have to be similarly cheap, and a setup that opens a connection pool will dominate the transaction it runs inside. The cost lands per replace, and capability reads pay nothing ^[22].

The repo's harness runs that same failed-upgrade scenario against a naive registry, cordis, and Moult, publishing raw numbers in `demo/comparison/RESULTS.md` ^[19]. The post repeats the repo's caveat: "environment-specific evidence, not a performance promise" ^[20]. Its broader claim, that in most plugin systems nothing is left running after a half-failed upgrade, rests on that three-way comparison ^[24].

On scope, the post puts HMR and Module Federation in a different layer: HMR reloads modules, Module Federation shares them, and neither promises that an upgrade either fully applies or fully rolls back ^[23]. Adopting Moult means writing the contracts down, since capabilities carry semver versions, consumers declare ranges, and each token declares whether it takes exactly one provider or aggregates many with `multiple: true` ^[14]. The enforcement evidence is nine replacement-transaction tests covering failed setup, failed validation, disposal ordering and resource cleanup ^[16], inside a suite of 145 tests run under both Node and a DOM environment for 290 green runs ^[17], with 15 invariants written down in `docs/guarantees.md` ^[18].