The direction followed would allow to contribute all JARs contained inside a given project to dependent projects. Thus such a project could act as an extension directory relatively to its dependent projects. This would however require to materialize such extension directories with true projects, and could be considered as one way to achieve this, but a true extension directory support should also exist, in a similar way as we allow users to directly refer to external JARs if they want.
We could add a new classpath entry kind for these. Now the next issue is: do we allow classpath variables to denote extension directories ? Presumably, this would be expected.
A classpath variable is not bound to a particular classpath entry, but rather to an IPath which is then resolved when the variable is substituted with a resolved classpath entry. The resolution process can either bind a variable to a project or a library, depending to what the IPath maps to.
In the library case, it can either be an archive file (*.jar, *.zip) or a binary folder (*.class files). The distinction is made again depending on the nature of what the IPath maps to, is it a JAR/ZIP file or a folder. Now, if we want to fit the extension directory support in this, it will be hard to distinguish in between a folder containing JARs or .class files...
We could however imagine that the syntax of the IPath would tell which one is expected to be resolved. For example, a path of the form "/SomeDirectory" would continue to indicate a binary folder, whereas "/SomeDirectory/*" would mean an extension directory. The benefit for this is that we actually do not need to add a new type of entry. We just add a third flavor of a library entry, the one mapping to an extension directory.
Thus, extension directories would just be particular cases of library ones, and be eligible in classpath variables.