Hi Tim, excellent work!
Coincidentally, I studied the same problem yesterday, but I did not yet complete to report my observations to you. So let me to this hereby:
After many hours of funny debugging, now I could create this minimum failing example:
Processor activeProcessevaluate: [self error. self inform: #foo]onBehalfOf: [] newProcess
Expected behavior: First, a debugger is shown, and after proceeding it, a dialog window is shown.
Actual behavior: Both the debugger and the dialog window are shown asynchronously!
Suspicion of someone who did not yet dive deeply into the activeProcess concept: The debugger resumes the wrong process, as the activeProcess concept simulates a different running process for the error, even against the debugger.
If my theory is correct, we would need to find a way to look behind the scenes of the activeProcess and use it in the debugging code. But first, I really need to learn more about this concept.
(Connection to our Context >> #at: problems: Probably no primitive issue at all, just the fact, that #at: calls itself recursively after the error was proceeded - similar like #doesNotUnderstand: does.)
This is an in-midst-of-work message; just did not want us to any duplicate or redundant work. Will have a closer look at this disgusting problem ASAP!
And vice versa, it would be very nice if you could keep me/us up-to-date!
(Oh, what a fun to debug a self-simulating system ...)
Best,
Christoph