I think that the overall goal is good but out of reach. Each single IDE is currently implementing the same ideas in different way: be able to handle different language within the same IDE and exposing the same user experience, incremental build, project management etc - with more or less success. This so far means that as a plugin provider (commercial or open source) you have to choose one horse (which is sad), wether pay the cost of porting your plugin as you can (which often you cannot afford).
IntelliJ EAP (upcoming v5) has already most of the things proposed in this JSR - f.e. an AST to represent the source code for all kind of language, a virtual file system, a build listener etc. The whole on top of PicoContainer.
Eclipse as much of it as well in very different forms though, the whole on top of OSGi things.
There is a JSR for dealing with the compiler as well (JSR-199) and have an easy way to gets its output in a rich format.
There is also the Java 5 APT and the JSR 269 that defines an AST as well (though not complete, method body structures are not exposed in the AST f.e.).
So that sounds to me yet another JSR. I 'd rather have someone write a good book on writing plugin for IntelliJ 5 or NetBeans and have the community draw best practices on how to do the common things, instead of locking everyone in a common API that would enforce the IDE folks to redo what they already have (in all cases, plugin folks have to rewrite..)
I have learned a lot in this area for the http://backport175.codehaus.org
plugins that I wrote for Eclipse and IntelliJ. I am sure each IDE community has to learn from the other, but I am not sure we all need a JSR for that.
By the way will there be a RI for that JSR ?