Perhaps that sounded a little hysterical :-)
(not in the funny way, though maybe that as well on reflection)

Re the wider critical scope, I just meant that I don't think the primary Editor 
Swing component(s) are instantiated from the Event Dispatch Thread either (so 
they could also be subject to potential concurrency errors). Obviously, once in 
place, they get events on this thread automatically, and so only any code 
explicitly using background threads 'thereafter' could run into concurrency 
problems.

The real issue is that virtually none of the GUI code is explicitly launched in 
the EDT, and so requires a substantial rewrite - which will occur when the 
editor rebuild begins

Just to confirm that this occurs very often for me nowadays; maybe one in 2 or 
3 times of using Open Specification. I therefore try to avoid it by using Open 
Recent, etc. where possible.

I guess I'm surprised that this doesn't happen for more people given the lack 
of EDT 'coordination' in the code. Maybe I'm just unlucky that the exact OS/JVM 
combination I have makes this more likely...

Might be of interest (apologise if not):
http://weblogs.java.net/blog/alexfromsun/archive/2006/02/debugging_swing.html

One of the Sun Swing developers gives a neat summary of ways to 
programmatically debug EDT errors, including a very simple AspectJ 
implementation that will root out all should-have-been-called-on-the-EDT errors 
at runtime.

resolved in editor 3.0

Changed state: Fixed