There is no change to the developer experience when a VM speculates about things like this. Browsers speculate about things that are more complex than this alr

There is no change to the developer experience when a VM speculates about things like this. Browsers speculate about things that are more complex than this already. It doesn't matter if eval is optimizeable in the general case. It only matters if this speeds up some cases without hurting others, on average. VMs and compilers are great at doing such optimizations already. You don't have to fork V8 since there are other JavaScript implementations. I recommend JavaScriptCore because it's the fastest. Similarly, Ruby, Python, and Lua all have multiple competing implementations and some folks pick them based on performance. Java is special, but that's because HotSpot emerged as the victor in a brutal multi-implementation battle for Java performance supremacy. Java used to have many implementations that all contributed something to our modern knowledge of VM design and this wouldn't have happened without the competition. Therefore, I think you're wrong on both numbers. Number 1 - this is not a semantically visible optimization; it just makes programs take less time on average; Number 2 - in practice, languages absolutely do have multiple competing implementations.