ZipPy, the initial implementation of Python on Truffle, was an intern project developed by Wei Zhang [1] while doing his PhD at UC Irvine, and continued by other students for a while. It was later re-implemented from scratch by an Oracle Labs team. I think that the main reason for a clean re-implementation was that the Truffle framework had evolved enough where it was easier to start from scratch than to rebase. Also, ZipPy was reusing the Jython parser, whereas GraalPython is using ANTLR [2].
Dynamic class loading is not supported on SubstrateVM because there is no infrastructure built-in to parse bytecodes, interpret them, etc. Adding those in SubstrateVM would defeat the purpose of having a thin layer VM. But, you are right: you could have an interpreter in the application itself. However a simple bytecode interpreter would have very bad performance. In fact that's how Truffle languages run on SubstrateVM. As far as SubstrateVM is concerned the Graal/Truffle stack is an application, albeit an application that knows how to interpret/compile other languages. So an interesting exploration path is having a Truffle based Java implementation that could be embedded in the image on demand, and which could load classes dynamically. You could still compile your known Java classes AOT and defer the dynamic classes to the interpreter. You might pay the extra cost for memory footprint, code interpretation/warmup/compilation time, etc., but you would be able to slowly migrate more Java code from dynamic compilation into AOT.
"The reason why we don't build CE on Mac OS is purely technical. Its because there was no OpenJDK 8 build for Mac that we could use. We hope we can change that soon. OpenJDK builds got a lot more regular with Java version >= 10."
GraalVM in the context of OpenJDK already runs on Windows. Native image generation on Windows is under development, should be available in the coming months.
[1] http://thezhangwei.com
[2] https://medium.com/graalvm/how-to-contribute-to-graalpython-...