I think there's a deeper problem with your proposal though, which is - why? I know you try and answer that in the article but I found it unconvincing. The JVM was explicitly designed to solve the problem you're trying to solve, as you clearly know, so a good starting point would be to much more thoroughly analyse why you aren't satisfied with it.
You say you have to "shoulder the runtime overhead of a garbage collector" but then name lots of languages you want to compile to Rust, all of which assume and require the presence of a garbage collector. Then later you talk about needing a good GC written in Rust. Well ... why? If you're gonna have to provide a GC anyway for practically every modern language, then the runtime overhead of this will be paid no matter what.
Having studied the JVM quite extensively, I don't see much in it that's obviously wrong or could be done wildly better, but I see a lot that's done right. If you re-walk that path, you will probably end up reinventing the wheel.
With regards to efficiency, a "unique design" is of little direct consequence; we are always mapping from one very different language to another, since assembly bears ultimately little resemblance to Java or Ruby or Haskell.
A language can be a bad compile target but that has more to do with runtime restrictions. For example, it's hard to build command line tools that start quickly if you target the JVM. Compacting GC can make interop with other languages hard (since objects get moved around). But Rust doesn't come with abstractions or an execution model that are any more heavy weight than C++ (which is no way a bad language for implementing interpreters or compilers, and has even served as a compile target on occasion); in fact it is a more conservative extension of C than C++ is.
Rust does impose a burden that is kind of like saying, your compiler/interpreter has to pass Valgrind+Coverity; but this is perhaps more of a help than a hindrance -- and it doesn't limit the kind of language you can write.
Only for those that don't know what they are doing.
There are plenty of JDKs that AOT compile to native code.
But the gcc folks keep it alive, because many of the gcj unit tests stress parts of the toolchain that other languages don't use.
So I imagine that for quick command line scripts that can live with an aged Java 1.4 API it might still work.
That program is 0.x seconds on Scala-JVM and 0.0x seconds on Scala-Native.
The last time I looked at this was a awhile back; maybe it was 0.3 seconds and I misremembered it.