Behavior of Ctrl+C with respect to unwind_protect_cleanup blocks

[Rik]

Maintainers,

Between versions 4.0 and 4.2 the behavior of unwind_protect blocks with
respect to Ctrl+C interrupts changed.  Previously, an interrupt was treated
the same as an error and the unwind_protect_cleanup block was executed. 
Now, the interrupt is immediate and returns control to the command prompt
without taking any other actions.

The issue was reported here: https://savannah.gnu.org/bugs/?51209e.  Sample
code is

unwind_protect
  while (1)
  endwhile
unwind_protect_cleanup
  disp ("executing cleanup");
end_unwind_protect

This is partly a philosophical question.  Should Ctrl+C be an immediate
escape path from all code including cleanup blocks that might result in
further hangs?  In another analogy, should it be treated like a
non-maskable interrupt?  Or should Ctrl+C be treated more like an IPC
signal indicating that the user would like control back as soon as is
reasonably possible?

The issue currently is that the behavior changed without anyone making an
explicit decision about this.  Currently there is m-file code that uses the
second interpretation.  For example, ginput.m uses it to restore callbacks
on the figure window.  If Ctrl+C is used then the figure can be left in a
mixed-up state.

--Rik