As with Core WebAssembly 1.0, the Component Model 1.0 aims to be a Minimum Viable Product (MVP), assuming incremental, backwards-compatible standardization to continue after the initial "1.0" release. The following is an incomplete list of specific features intentionally punted from the MVP. See also the high-level post-MVP use cases and non-goals.
While the Component Model MVP allows strong software isolation of capabilities (in the form of link-time imports and runtime handles) there is currently no way for a host component to execute a guest component robustly in the face of traps or runaway resource memory/CPU usage. A post-MVP "blast zone" feature would allow a parent component to dynamically instantiate a child component in a separate "blast zone" such that a trap in the blast zone could be safely and predictably handled by the parent outside the blast zone. Furthermore, the parent could use a non-deterministic timeout or resource quota trigger to preemptively inject a trap into the blast zone.
The original Interface Types proposal includes the goal of avoiding a fixed serialization format, as this often incurs extra copying when the source or destination language-runtime data structures don't precisely match the fixed serialization format. A significant amount of work was spent designing a language of adapter functions that provided fairly general programmatic control over the process of serializing and deserializing high-level values. (The Interface Types Explainer currently contains a snapshot of this design.) However, a significant amount of additional design work remained, including (likely) changing the underlying semantic foundations from lazy evaluation to algebraic effects.
In pursuit of a timely MVP and as part of the overall scoping and layering
proposal, the goal of avoiding a fixed serialization format was dropped from
the MVP by instead defining a Canonical ABI in the MVP.
However, the current design anticipates a future extension whereby lifting and
lowering functions can be generated not just from canon lift and canon lower, but, alternatively, general-purpose serialization/deserialization code.
In this future state, canon lift and canon lower could be specified by
simple expansion into the general-purpose code, making these instructions
effectively macros. However, even in this future state, there is still value in
having a fixedly-defined Canonical ABI as it allows more-aggressive
optimization of calls between components (which both use the Canonical ABI) and
between a component and the host (which often must use a fixed ABI for calling
to and from the statically-compiled host implementation language). See
list.lift_canon and list.lower_canon for more details.
Originally, Module Linking was proposed as an addition to the Core WebAssembly specification, adding only the new concepts of instance and module definitions (which, like other kinds of definitions, could be imported and exported). As part of the overall scoping and layering proposal, Module Linking has moved into a layer above WebAssembly and merged with the Interface Types proposal. However, it may still make sense and be complementary to the Component Model to add Module Linking to Core WebAssembly in the future as originally proposed.