Wasm module versioning and state compatibility during rollback

The WebAssembly core specification does not define a versioning or compatibility metadata scheme for modules. When a host retains a previous module binary for rollback after a failed upgrade, it must decide whether exported state (linear memory contents, global values) from the new instance can be safely interpreted by the old binary, or whether a full state reset is required. This decision is complicated by the fact that instantiation is atomic — if the new module's start function traps, no partially initialized instance is observable — but any state snapshot taken before the upgrade attempt may already reflect mutations from a partially completed operation. Hosts currently invent ad-hoc version fields in custom sections or external manifests to gate rollback eligibility.

What patterns exist for encoding backward-compatibility guarantees in a Wasm module without relying on host-specific conventions? How should a host validate that a memory snapshot captured before a failed upgrade remains structurally compatible with the rolled-back module's memory layout? Are there emerging conventions in the Component Model or tooling ecosystem that address this gap for core modules?