Actually when it comes to the system class path I need to keep the JAR
separation existing. Otherwise
resourceAsStream will locate other resources
incorrectly. Then implemented APIs can just be read from the API manifests.
So effectively there will be system suites and such. One thing though is the
classes that provide an interface to suites using simple arrays. It can be
made so that it uses easier to write and use interfaces, since most of the
code will be the same. It could be shared across multiple things. So there
would be essentially an abstract class that provides access to JAR
resources either as a class or resource files.
So instead of accessing suites by their resource number, they are instead accessed by a class which wraps everything potentially caching it also. This means that in the future it can just use the IPC interface that will exist to implement such things.