To start with a bit of project history, we love Wasmtime and that’s our core runtime of choice! Before wasmCloud 1.0, e.g. from 2019-2023, we only used Wasm modules with our own custom ABI. Literally everyone was doing this at the time, to run Wasm you either needed to adopt a platform with a custom ABI or invent it yourself and re-solve all the same problems. The component model and its canonical ABI was a huge opportunity for us to stop maintaining our own and integrate into the ecosystem; now you see examples in projects like Moonbit which just work with wasmCloud out of the box, huge win for us https://www.moonbitlang.com/blog/component-model.

On the WASI side itself, I understand that moving WASI from p1 to p2 was a big but necessary leap. Everyone wanted sockets and HTTP and there was no easy way to rev the monolithic ABI of preview1 to add what was needed in small increments. That’s why you see adapters to move from p1 to p2, which wrap a Wasm module with component metadata, but a component actually just straight up contains the module (you can see it if you look at the textual representation.) We’ll have the same thing from p2 to p3. Not to mention, some systems that don’t support the component model like in Node.js actually “unbundle” the inner module from the component and that works just fine. So from what I understand, module support will never be dropped.