From what I remember they are not always redundant, but I'm not 100% sure they are both needed.

`suspendedContext` from Process is always the top context of a process. After execution actions like Step Into, Step Over, Step Through it will be the same as interruptedContext in the debugger.

They will be different when opening the debugger as a result of an exception.

Exception>>#debug triggers the workflow for opening a debugger. This uses `self signalerContext` as the context that is being debugged. This is the context where the exception was raised and this will be put in the interruptedContext. As this point the execution of the current process is not over and it will continue up to `MorphicUIManager>>#debugProcess:context:label:fullView:notification:��` where the current process is suspended. At that point the two will be different, as suspendedContext will be the context of the method MorphicUIManager>>#debugProcess:context:label:fullView:notification: and the interruptedContext the context that triggered the exception.

But it might be that they are not both needed. One�� possible option might be to force the process to step to the context that raised the exception when the debugger is created. For example in��DebugSession>>process:context:.

Apart from when opening the debugger I do not know if there is another situation where those two can diverge.

Cheers,

Andrei