I am not sure what is wrong with my tone.

I did not choose a random external library and starting to criticize it.

This is a core component. And

"Because it is there just for spotter and will be deleted ASAP.

We know that it is bad. Normal fix requires too many changes."

is not an excuse for badly debuggable code.
I don't like to have quick-dirty-throwaway-hacks in the core.

There is a real demand for debugging this code.

The attached screenshot shows a common issue with inspector panes.

The available space would suffice for all tabs (secodn window) but the default

size shnrinks nearly all tabs (first window).

The normal way to understand and trying to fix this issue, is to put some

"self halt" at some point for the layout processing.But this does not work here

because *all* exceptions are catched.

And changing the code to actually execute the exception won't work either, becuase this

will throw all other (previously cachted) exceptions (what is wrong with initializing the font property properly or

checking for ZeroDivide?)

And this is frustrating.

And I hope no one sees and adopts this code, just because it is the way our own

core tools are built.

BTW, your LazyTabGroupMorph class is another bad example. It subclasses
TabGroupMorph, it
calls super initialize,

removes all created and added morphs from its super class and

recreates and replaces them with its own.

nicolai