as with all tech, like it or not, specifics are important… since the fix or resolution is dependent on exactly whats going on , rather than what the user perceives is going on…
if it’s just heavy CPU load, then I would expect (with patience) eventually the patch will respond and return you to the main menu, and so eventually you’d be able to shutdown.
caveat : unfortunately, those pesky details rear their heads again here… somethings might use timers, which might screw up and things become a bit unpredictable - either making functionality, like menus, work intermittently or not at all.
in this case the shutdown shortcut may or may not work, due to those timing issues, as we have no way to get more priority to the mother executable, in fact its actually running at a lower priority than audio (which is what you normally want)
however, if the patch crashes (due to an external, or pd acting up) , then its a different thing entirely - the patch cannot return the control to mother executable.
I have actually talked with @oweno about a different solution for this, we could be periodically checking the patch is running and if we find its died, we could then ‘cease’ control, and return to the main menu.
likelyhood is , different people are describing both… this is why I use try to find out some specifics, rather than just the organelle has crashed or frozen - because from a technical standpoint this doesn’t actually tell us anything at all…