Enviroment abstraction for eWASM code execution

[tawaren]

I'm developing a smart contract language and intended to compile to eWASM but because of some unusual complex requirement I could not come up with an efficient runtime desing that fits into the current eWASMS account model.
This made me thinking whats missing and how the model could be made more flexibel and open to alternative approaches without introducing to much changes and came up with something I like to share.

1. Store deployed eWASM code seperately from account states.
2. Add a deploy code function to the Ethereum enviroment interface
   2.1. The function takes wasm code + an wasm interface does the validation and the metering etc...
   2.2 The deployed code can call functions on the provided interface instead of the Ethereum enviroment interface.
   2.3. The contract calling the deploy code function must export the functions on the interface
   2.4. The code is stored under its hash (code deduplication) in the code tree
   2.5. The hash/key of the processed and stored code is returned
3. Add a instantiate code function to the Ethereum enviroment interface
   3.1. The function takes a code hash and loads the corresponding code and instantiates a eWASM module for it (including the execution of the start function).
   3.2. The functions imported by the module are forwarded to the functions exported by the caller.
   3.3. after the start function is executed a handle to the instance is returned to the caller (This is not necesary if 4 is not possible)
4. Add a execute function function to the Ethereum enviroment interface
   4.1. The function takes a instance handler a function name and its parameters (I'm not sure if that is easy or hard or impossible to implement, because of the dynamic number and types of parameters)
   4.2. The corresponding function in the instance is called and the result is returned
5. Add a close instance function to the Ethereum enviroment interface that discards the module (only necessary if 4 is possible else just discard after start function execution)

This extensions allows a smart contract to manage some sort of sub contracts in its state.
These sub contracts interact with a different interface that can use different state isolation properties and enforce additional guarantees.
The contract could even use another kind of low level code for its subcontracts and transpile it to eWASM on deployment.
It may even allow to deploy wasm contracts compiled for other blockchains on Ethereum by deploying it as sub contract to a contract that provides the same interface as the other blockchain and then simulates its functionalities.

The only problem I see (there are probably many more i'm overlooking) is the interaction with state rent as a master contract can get big and we would like to just archive some part of its state if not payed for it instead of its whole state.
The question who pays rent for the code falls into the same category.