Clarifying lift-then-lower and lower-then-lift semantics

This issue was originally discussed in https://github.com/WebAssembly/component-model/issues/9 and I believe the intention was that "degenerate cases" of pairing lower/lift would turn into a function that immediately traps. Interpreting the current canonical ABI, however I think may result in slightly different semantics.

Lower then lift

For this situation my understanding is that when the final function is called it'll call def canon_lift in the explainer and internally call the def canon_lower. My read is that in this situation the final function is expected to work correctly in the sense that when called will lower arguments into the canon lift options, immediately re-lift them from the options specified in canon lower, call the lower'd function, and then do the opposite for the results.

Effectively, to confirm, this use case is not intended to trap at all purely by construction and it could be part of a component. It's a bit silly to configure and does require that the linear memories and such are probably all the same, but otherwise this is a valid configuration that engines should run?

Lift then lower

For this case it's the opposite of the above where canon_lower is called first then canon_lift. This is slightly different where canon_lower immediately sets a flag which will cause canon_lift to trap. This means that by the time the canon_lowerfunction calls thecalleewe're guaranteed a trap will happen. Before this happens thoughcanon_lowerexecutes thelift operation for the arguemnts. In general lifting is a noop in terms of side effects within the module itself, but I believe this does mean that runtimes still have to validate all the arguments that are being lifted (e.g. that enum` discriminants are in-bounds and such).

Is this argument validation intentional? Or should instead the pseudo-code for lift/lower be updated to have a lifted-then-lowered function immediately trap without looking at the arguments at all?

Start with design/mvp/CanonicalABI.md and the discussion in WebAssembly/component-model#9. Trace the lift-then-lower and lower-then-lift pseudocode, focusing on argument validation and trap timing. Done means the intended semantics are decided and the canonical ABI text or pseudocode clearly reflects that decision.