Thanks for your interest and thoughtful response. I think you hit the core of our disagreements with, “Kadena simply does not have the same concerns as Ethereum when it comes to consensus…” When you design for different use-cases you get different designs.
From my point of view, Pact is not so much a VM as a very rich programming language, designed for writing safe programs. Whereas the EVM and eWasm are fairly austere abstractions of real machines upon which implementations of multiple programming languages can be built. In that tradition compact bytecode for a simple stack machine is a very common design.
I brought up crypto codes because the EVM can’t get at those battle-tested C codes you mention unless they are already built into the clients. These are written by different teams in different languages with different available libraries, and not all of them can link to C. Providing a growing number of crypto routines on a growing number of clients is becoming a burden, so we want to put these routines on the blockchain, whether in EVM or eWasm bytecode. They have to perform nearly as well as compiled C when run.
The EVM can’t just learn from its mistakes and start over, it has to evolve. What we plan to do over time is deprecate dangerous operations, provide safer alternatives, and provide for provably correct interpreters and compilers for EVM code. As importantly, we will make it easier to prove that EVM programs meet their formal specifications.
We can’t provide all that Pact itself provides, but we can make it a goal that the EVM and eWasm become secure, performant platforms for implementing safe languages like Pact.