> I understood the changed behavior. Eliot is right, we need to update Warning
>>> #defaultAction so that it behaves like Halt >> #defaultAction. Let me
> explain why...
>
> What is an Exception? An abstract base class for the exception handling
> system.
> What is an Error? A non-resumable exception.
> What is a Notification? A resumable exception that does not raise a debugger
> if unhandled.
> What is a Halt? A resumable exception that does raise a debugger if
> unhandled.
>
> ---
>
> So what is a Warning? Actually in 4.5, warnings behave just like Halt, that
> is, as resumable exceptions that do raise debuggers if unhandled. In 4.6,
> this still works for normally executed ("do-it") code but not in the
> debugger.
>
> Why is that?
>
> We just extended "Processor activeProcess" to return the effective process,
> which is different to the active one while debugging due to Process >>
> #evaluate:onBehalfOf:, to support debugging process-local state. This is
> fine.
>
> What changed from 4.5 to 4.6 in the control flow of Warning >>
> #defaultAction?
>
> Eventually, we get to MorphicProject >> #spawnNewProcessIfThisIsUI. But now
> in 4.6, the comparison is *false when debugging* and hence *we do not spawn
> a new UI process*. Until then in 4.5, this spawning of a new UI process
> cleaned up debugger stuff in the current stack (see Debugger >>
> #informExistingDebugger:label:) and thus also *dropped the current progress
> of step-over*!
>
> What was the current progress of step-over? Well, our example is this:
>
> 3 timesRepeat: [Warning signal].
> Transcript showln: 10 factorial.
>
> We want to step-over the #timesRepeat: call. Now go see Warning >>
> #defaultAction:
>
> defaultAction
>         ToolSet
>                 debugContext: thisContext
>                 label: 'Warning'
>                 contents: self messageText, '\\Select Proceed to continue, or close this
> window to cancel the operation.' withCRs.
>         self resume.
>
> What we do not execute anymore if we spawn a new UI process -- due to the
> clean-up of the debugger stack -- is "self resume." That call just removes
> the Warning's calls from the stack. Thus, we keep going in the surrounding
> step-over progress and get all warnings at once.
>
> In a nutshell, the current implementation of Warning >> #defaultAction
> exploits a very nasty side-effect in 4.5 (even a buggy one), which got
> finally fixed in 4.6 when we started evaluating code on behalf of another
> process.
>
> ---

Thank you Marcel!!  I'm very glad to hear that this is the result of
fixing things instead of breaking things.

> Warning and Halt behave exactly the same. We should make Warning a subclass
> of Halt and extend the message text as in its current #default action.
> Warnings *are no* Notifications. They never were.
>
> Any objections?

None initially, but let's just do a quick thought-iteration on
potential impacts.  The only one I can think of is if someone ever
wanted to handle Halt to change or enhance debugging, as in:

  [ "...code to run..." ]
    on: Halt
    do: [ :halt | "invoke special debugger?" ]

that such code would be triggered by Warnings as well (which may be
fine, I don't know).

I see Warnings as an application-level thing whereas Halt as a
system-level thing.  Even though Warnings could inherit the behavior
we want, I think we should at least consider having Warning be its own
subclass of Exception.  I know this means it would duplicate the
one-line method in Halt but, at this level of the system, proper
separation of concerns supercedes the duplication of a small amount of
code.  So which is the proper separation of concerns?

We are back on track, thank you again!!!