I think we can get there eventually with respect to AOT (and frankly Chris is likely to get there first - as much as I have a general aversion to the JVM, the infrastructure they are getting with Truffle/Graal and now Substrate is impressive), but to solve the issue properly will take a lot of heuristics, coupled with getting some kind of agreement on various minor semantic changes to indicate compile time/runtime split.
I also really badly at some point want to analyze a bunch of Ruby code - as in crawl all the Ruby on Github big - to look for things like use of eval(), redefinitions of core methods, weird code loading tricks etc. to get an indication of how these things are actually used. Delineating what people actually do would be a big step forward in figuring out what to do about it...
I suspect, but don't know for sure, that most of the disaster-scenarios we've thought up involving Ruby sees little enough usage outside of people going "look what insane thing I can do with Ruby" that for some it may be better to just break code and fix it.
I was telling him that from my point of view, given the work done in languages as dynamic, meaning Lisp, Dylan, Smalltalk, that from my naive of view (I know Ruby only superficially) that could be applied to Ruby as well.
He also answered me along those lines, that idiomatic Ruby abuses more the dynamism than those languages.