Thanks for the feedback!
This specific PolkaVM-specific Solidity dialect should get its own name, like “P-Solidity”, with a versioned specification [of its own RISC-V assembly, cryptographic computations, whether feasible or not].
By using solc as the compiler front-end we do hope to get away without introducing a Solidity dialect. We’d specify what either works differently (at runtime) or is not supported. The goal is that a vast majority of dApps shouldn’t notice and work fine without code changes.
The largest deviation will be how deployments work. However this only affects the developer side of it and can be worked around with tooling. For users (anyone just doing regular calls), existing tooling, wallets etc. will just work given we also add compatible RPC (which we could).
However, I expect a vast majority of features to just work. The relevant ZKSync doc section should give you a good taste as most of it applies to our case too.
I’m not sure it even needs an RFC… In priniple, you could even link together contracts written partially in EVM and partially in Rust. It’s purely a matter of dev tooling, but the chain won’t care.
Yeah for the runtime and chain, the contract Language is fully opaque. A Solidity contract can call anything as long as the callee respects the Solidity ABI encoding (hypothetical the same would apply for dynamic linking). We want to provide ETH precompiles though.
As the Relay Chain is not suitable for smart contracts, I would like to see system chains (specifically AssetHub) incorporate the
contractspallet
I do agree! I’ve collected and published ideas and thoughts around it here 
What is the best vs worst case timing of inclusion for this?
I think the sooner we push it to Kusama the better, starting with AssetHub first until other system chains are available. We just need to make sure to not introduce any new attack vectors.
I have closed RFC #66 in the expectation of resubmitting it as soon as
contractspallet is sufficiently mature – when could that be?
I don’t think we need to wait any longer as I don’t expect this final runtime to diverge much from contracts as it is today (after all, it is modeled after Ethereums contracts model and already highly compatible). Even if a couple things wind up differently in the end, shipping contracts as it is today paves the way and makes this a more incremental process overall 