So assume it doesn’t and fixit up if it ever does. That’s the basics of JIT compilation!

One reason is that it makes it significantly harder to reason about the performance of a program, because the behavior of the JIT is based on all kinds of internal state and pattern-matching rules, which are typically hard to expose in a comprehensible way. The more complexity you add to the optimization and deoptimization process, the more inscrutable the performance characteristics become.

Another reason is that it encourages developers to use unsafe patterns. If programmers have a choice between `obj[key]` and `eval("obj." + key)`, why would you put effort into optimizing the one that has the potential to blow up if "key" has funny characters, when a safer, cleaner alternative exists?

Number 1: you say "eval is optimizeable", but optimizing eval in general is incredibly difficult. It's true that you can add optimizations for specific situations. But every time you do so, you expand the surface area of the boundary between "efficient" and "inefficient", and it becomes harder to maintain a mental model of how any given chunk of code will be executed. (For example, in Python, strings are immutable; when concatenating strings in a loop, the intermediate copies can be optimized away but only sometimes, which means that pattern is generally avoided as a matter of good coding style. Tail-return optimization in Scheme is a useful trick that suffers from similar drawbacks, which is probably why you don't see it implemented in a lot of other languages.)

I'm skeptical that adding this type of complexity results in a better overall developer experience. Remember, code is written not just for the compiler, but also to be read and understood.

And number 2: in practice, most languages don't have multiple competing implementations at the level of complexity you're talking about. When your compiler gets to the point of doing sophisticated JIT optimizations, maintaining it requires a lot of specialized knowledge and experience. It's impractical to fork a project like V8 or Hotspot to add a specific new optimization. So individual runtime environments usually aren't subject to competitive pressure, except from entirely different languages.

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.