I also would like to put in a fix... eventually... but... I'm a having a really hard time of thinking of a way this could actually be fixed. Starting up a new JVM to run the greclipse compiler just to set the user workdir to satisfy that transform is out of the question. That would be a major change and probably come with a major performance hit as well.
Hacking around with setting "user.dir" system property might work, but it is very risky in the multi-threaded environment of Eclipse, where several compile things may be executing simultaneously on different projects.
It may be that there isn't really a good way to fix this, unless the plugin itself is changed to work in a way that is more amenable to running in STS. I also thought about this a bit, but even that seems quite tricky. How would the ASTTransform in the plugin be able to access the config file it is after, if not by using a relative path of some sort?
Tricky issue, so a fix may not be forthcoming for a while.
The option to disable incremental deployment and deploy grails-builts war files "as is" will probably help. That seems within reach, but I won't be putting that into the next release yet. I played with it a bit and it was too unstable still to risk it.
So... I'm glad you are okay with working the workaround for now.
BTW: the flushing procedure described above may be simplified. It looks like just doing a "clean" of the project should flush both classes in the classloader and the .class files on disk.