Ah, i thought i got a solution applying mantis patch for 
DependentsArray, but no, it still bugs from time to time.
After some time, the code pane does not occupy the whole window,and/or 
overlaps with class comments...

The problem is located in the method below. Sometimes, no AlignmentMorph 
will have a layoutFrame bottomFraction = 1.
Consequence is that the #browserLowerPane property is then missing, what 
you can observe by exploring the BrowserCommentTextMorph in the 
dependents of a broken Browser.

If someone want to help tracking, simply add following halt:


BrowserCommentTextMorph>>noteNewOwner: win
	super noteNewOwner: win.
	self setProperty: #browserWindow toValue: win.
	win ifNil: [ ^self ].
	win setProperty: #browserClassCommentPane toValue: self.
	self setProperty: #browserLowerPane toValue: (win submorphThat: [ :m | 
m isAlignmentMorph and: [ m layoutFrame bottomFraction = 1 ]] ifNone: [
		self halt: 'DEBUG ME, I JUST LOST MY LOWER PANE'. nil]).


Of course, since I added the halt, the bug refused to show up!

I suspect it is related to World loop and other-complicated morph layout 
management. Maybe if some Morph wishing to display happens to inquire 
its bound, fullBounds or something that triggers some bound/layout 
machinery just before the BrowserCommentTextMorph had time to install 
correctly...

My clues: if you try to debug with 'toggle breakpoint on entry' on above 
method, then the bug will show every time.

Broken AlignmentMorph has a bottom layout of 0.75.
This is the layout of the PluggableTextMorph holding code before the 
BrowserCommentTextMorph is removed.
I guess this layout propagates incorrectly to the above AlignmentMorph, 
don't really know how (too hard to debug a World loop without interacting!).

A possible workaround might be to search for alignmentMorph with a 
bottomFraction = 0.75 or maybe nil ifNone... and fix it back to 1.
But I don't like such heavy workarounds.

Nicolas