rationale for simulation guard in BlockClosure>>newProcess?

    the simulation guard in BlockClosure/BlockContext>>newProcess (primitive 19) prevents creating processes during debugging which means, amongst other things, one can't step into displayingProgress: blocks which is /very/ annoying.  What's the rationale?  My first unconsidered instinct is that it's OK to crate and schedule processes during simulation; one simply shouldn't expect them to be debugged.  Alternatively one could offer to open a debugger on the new process (perhaps wrap it in some object such that when it receives resume the debugger is spawned?), create the process or fail in doPrimitive:method:receiver:args:.  What do those in the know, know and think?

(SystemNavigation new browseAllSelect: [:m| m primitive = 19])

[BTW, re being able to debug a process when it becomes resumable, it would be good to have the VM's resume primitive do some sanity checking, e.g. failing if the receiver's context doesn't smell right, or if myList is not nil, which would allow using myList to tag a process created during debugging.  The Cog VM fails the resume primitive if suspendedContext is not a context]

best

Eliot