My rule of thumb: use checked exceptions if and only if your exceptions are not supposed to be rethrown and must be handled by the caller directly. These cases are very rare, but I recently had one them.
Graal can run in dynamic and aot compilation mode. If you feed profiles into aot from a test run you can get pretty close to dynamic compilation peak performance.
We have lots of infrastructure depending on mx. Infrastructure that no other build tool provides as far as I can tell.
In the end every build tool sucks. Sometimes you just need to be pragmatic. Mx integrates with maven pretty well and it generates ide config for intellij, eclipse and netbeans. Moving to a different system is probably not worth the cost atm. And it's not complicated to use at all. E.g mx build builds and mx gate builds and tests. Mx unittest runs unit tests.
As written below. Graal.Python is not yet open source. But you will hear from us soon.
When executing on Java we are dependent on hotspot to support it in the native bytecode interpreter. In truffle interpreters we made some successful experiments with tail calls emulated using exceptions. It's pretty slow in the interpreter but as soon as graal optimizes it, it just turns into a tailcall loop.
Here is some more info:
http://epub.jku.at/obvulihs/content/pageview/508465
You may find some blog posts about truffle and tailcalls as well.
It started as fork of Zippy. It changed very much since then. You can download the binary as part of graalvm. It's not yet open source, but it will be. It's just not ready yet.
Graal dev here. We're testing on jdk 8,9,10 and 11. We are packing graalvm with jdk 8 atm to keep variability reasonable. Graal will be integrated into the JVM soon with project Metropolis: http://openjdk.java.net/projects/metropolis/
Graal is used for many more things than dynamically compiling Java. Besides others it's used for SubstrateVM (closed world AOT compilation) and Truffle languages like TruffleRuby, Graal.JS, FastR, Sulong(llvm integration) and our newest member Graal.Python.
Graal comes out of Oracle Labs. The build tool mx is short for Maxine, the spiritual predecessor of the Graal project. If you don't know mx it's quite intimidating and ugly. It's Python written by Java developers. But it does it's job coping with our not so standard building and testing requirements. No we don't run mx on Graal.Python yet, but we are working on it for full build tool metacircularity ;).
Your mission seems to be matching with what we are trying with Graal and Truffle. The Truffle API aims to be stable as well. We also provide basic building blocks like an object model. I am curious how you plan to support speculative optimizations that need to deoptimize and reconstruct interpreter stack frames? In my experience that's essential for building high performance dynamic language implementations.