The whole point of having a type system is to endow program syntax with verifiable annotations that make validation easier. So if you wished to allow for otherwise "expensive" validation without overly impacting startup speed, the natural way of doing that is to extend the type system itself, in a way that offloads burden from the verifier to the producer. Arguably, this is exactly what WASM did when it implemented SSA phi-nodes via block return values and then extended those to multiple-value returns.
Yes, this generalizes well. The same producer-side annotation pattern shows up in every type-system extension WASM has shipped: typed function references encode signatures into the reference type, so indirect calls through them don't need runtime signature dispatch; the GC proposal uses declared subtyping via explicit (sub $X $Y) clauses, so subtype checks are chain walks instead of structural equivalence; exception handling uses nominal tag identity, so try/catch dispatch matches by name instead of structurally.
Each extension grows the type system and the producer's job, and the verifier stays linear. JVM made the equivalent move retroactively when StackMapTable became mandatory in Java 7, explicit type annotations at branch targets so the verifier doesn't compute joins via fixpoint. WASM was designed with that lesson built in from day one.