Should the modified state also be returned (not just the state root)?
I don’t think the modified state is necessary for shard nodes since it will be the relayers’ responsibility to i) package transactions with their merkle proofs and ii) to store whatever state is necessary to perform future state transitions / provide merkle proofs. Therefore in the relayer runtime there should be a way for retrieving and saving the modified state, but not in a shard node.
As for the implementation, I’m not sure which is preferable: the beacon chain contract explicitly returning the modified state and the shard node discarding it or making use of the context object I proposed.
What other data from the shard state, shard block or beacon block should be made available to the scripts?
From Vitalik’s optimistic receipt root design, expected_roots would be another important data struct to provide to execution environments.
A good option here is to make them [extensions] system libraries, which can be implemented natively by clients if they choose to do so.
I definitely agree with providing a single implementation of these, but I would argue that it would be better to provide them as another execution scripts – aka wasm precompiles. I believe this is a more favorable approach because it minimizes the overhead for clients even more and allows upgrades and new scripts to be added without hard forks. Obviously performance is crucial for these extensions, so if we can’t securely compile them to native code from wasm they may have to just be implemented in the client.