Thanks @kianenigma for calling out the “Journey to Scale”.
I do agree with what you wrote.
Since writing that initial post, I have more clear vision on the path of a contract. Specifically, through the “Contract Hosting Service” (codename CorePlay), we will be able to provide a JAM Service which can take a smart contract OFF of an L1 blockchain, and all the limits of that environment, and onto its own dedicated or shared core (or multiple cores? not sure).
So contracts will be able to basically access the full throughput of an L1 blockchain for just their application. This is certainly a journey to scale.
In this context, the perfect world would mean the same bytecode used with PVM on the L1, would directly work with the PVM inside of JAM, but I guess that is something which depends on how the Contract Hosting Service is implemented, and what is possible.
In many ways, the Contract Hosting Service may lead to the obsolescence of L1 smart contract chains, since as you mentioned, it should allow for synchronous composability when two or more contracts share a single core, but also all the scaling horizontal scaling of parallelization of contracts which do not interact with one another. It is the best of both worlds, probably at some additional technical complexity, but complexity which should be entirely handled by the Smart Contract Hosting Service.
I agree with both of these checkpoints.
Calling a parachain a cloud service is wrong. But we should also be able to reference them as “rollups”, or blockchains hosted on the cloud via the “Blockchain Hosting Service”