Hi Lou,
Yes, that is the EtClassDefinitionCompiler hooked into the browsers.
It actually received some pretty big updates in both 10.0.0 and 10.0.1 to make it more friendly, as it does impose constraints which are either appreciated or not:)
I've had support cases involving both sentiments. However, I really paid attention to the negative ones and tried to make some improvements so its not too draconian when folks are attempting to refactor in the editor in an order in which they prefer. There were a lot of situations before 10.0.1 that produced a sort of "chicken-and-egg" problem when you were trying to refactor.
There is actually an interesting bit of history here, which some folks might like more information on, regarding why we felt the need to develop this. I'll give some background, and then conclude with what the latest updates do.
First, why was this feature developed?
When performing a refactoring in manual steps in the browser, as opposed to an automated workflow like the various refactoring browser actions, the onus is on developer to refactor the code from one valid state to another. The refactoring tools are responsible for doing this as one logically atomic transition. Developers in the browser must do this in a sequence of manual steps. During this time, the methods and class definition are often out of sync with each-other. Unlike the way a lot of other language implementations and environments work, the browsers (used to) allow the class definition to be shaped separately from the compiled methods which may refer to it. Even worse, the bytecodes are cached, so there are minimal opportunities for recompilation from source to recognize that the class definition and a given method are out of sync.
The most common situation we've seen (and experienced) in the past is the removal of instance variables, but methods remain that still refer to it. Methods that refer to it have cached bytecodes that don't see it as a name, but rather an offset into the object. When this code is executed, any number of outcomes can occur that make it extremely time consuming to track down. In the best case, your running program will all the sudden inexplicably GPF. In the worst case, the bytecode instvar offset now refers to "something else". It could be another instvar or some bytes from an adjacent object which just happens to look like a valid object (i.e. tagged small integer). And your program may continue to run for some time until you have all the wrong answers. Even worse, you export your code (along with your cached bytecodes) to someone else...maybe it even makes it into your build system. We've seen all of this, both because we are imperfect ourselves and have performed incomplete refactorings, but also because it used to fall in our laps as support cases. And with so little traceability back to the root cause, it cost everyone involved a lot of wasted energy and time.
In a perfect world, we as developers are all perfect and perform these refactorings exactly as we intended. But it isn't true, I have the support cases to prove it and my own personal experiences to match them. If the penalty for getting it wrong were not so high, we might have been content to just let it go...but it was becoming very costly. And the decision was made to develop the EtClassDefinitionCompiler in the hopes of squashing these issues for everybody.
Since that time we have not had a support case involving this issue. On the other hand, it does impose constraints. Some were unnecessary, and thanks to some support cases, I believe we have improved that situation in the latest releases. But lets be honest, we're a community of folks that back a highly flexible and reflective environment with a very dynamic type system...constraints are not something that we appreciate:) The very first thing that went into the EtClassDefinitionCompiler was the Enabled (true/false) class variable to just disable it...though hopefully people might now understand why I was reluctant to broadcast that.
10.0.0 - Turn it off for some time
Understandably, there were just some situations coming up where it was too constraining. I received some support cases to this effect. Of course, I offered them the way to disable it, but I thought I would do one better and integrate it with the browsers. If you see the red squiggle come up in the class definition browser, but feel strongly you must continue forward in the order you wish, now you can hover over the squiggle which brings up a calltip with an up/down arrow. Press the down arrow and it will allow you to disable the class definition browser for a period of time or until image restart.
10.0.1 - Consider proposed class definition
Thanks to a support case, an area was missed that was making things more constraining then it should have been. Some folks were trying to change the superclass in the editor only to find that it wouldn't let them save it, but should have been valid to do so. This was because the class definition compiler only considered the shape of the current class and its current hierarchy, not the shape that would be true if the class was reparented to what was being requested. Now it looks at the shape of the proposed superclass.
I hope this was informative and provided some interesting background. Have a great rest of the weekend!