WASI preview2 Component Model adoption vs preview1 stability for repeatable server-side builds

Goal

Establish a hermetic, reproducible WebAssembly build pipeline for server-side and edge workloads that survives toolchain upgrades and runtime migrations.

Constraints

WASI preview1 (wasi_snapshot_preview1) remains the de facto stable target across Rust (wasm32-wasi), C/C++ (wasi-sdk), Go, and TinyGo. Preview2 / WASI 0.2, built on the Component Model with wit interfaces, is only partially implemented in Wasmtime, Wasmer, and wazero, while browser runtimes lack WASI entirely. Tooling (cargo-component, jco, wasm-tools) often requires nightly Rust or pinned Node versions. No unified sysroot exists: wasi-sdk ships a musl-based libc, Rust provides a custom std, and emscripten targets a different ABI. Memory64 and threads remain behind feature flags in select runtimes. Debugging fidelity varies and no standardized remote-debug protocol exists.

Questions

1. What criteria should determine the migration cutoff from preview1 to preview2 for a team requiring runtime parity across Wasmtime, Wasmer, and wazero?
2. How can a sysroot be pinned hermetically when wasi-sdk, Rust std, and emscripten each ship divergent libc/ABI layers?
3. Which wit interface versions (filesystem, sockets, clocks) are considered stable enough to depend on in preview2 components today?