This answer is a qualified guess, I don't know the inner workings of Personal Paint, and it is the first time I've heard of it.
Not unmaskable but...
They are probably right in that ejecting a floppy is the only user accessible and system friendly way to trigger an interrupt. It is, however, not as fool-proof as the real non-maskable interrupt, or even as reliable as a "normal" but externally triggered interrupt.
...what they really mean is:
Let's assume an unexpanded Amiga 500 as the base case. The only thing plugged in is a mouse, a monitor and a power supply. Switching off the power supply is obviously not going to save your precious drawing, and you can't do anything with the monitor, which leaves the mouse, keyboard, floppy, and the built-in ports. Unless you're MacGyver, you don't want to bend a paper clip and probe the random pins, taking these ports out of the equation.
The mouse and keyboard is handled by
input.device. You can add input handlers to have whatever code you like run when you press a key. You could add your rescue code to an input.device handler and have it trigger on an unusual key. This will, however, run as a plain old task.
The floppy is normally handled by
trackdisk.device. You can add an interrupt handler that triggers on disk changes:
The trackdisk device lets you add a software interrupt handler that will
be Cause()'ed when a disk insert or remove occurs.
This sounds good.
Cause() refers to exec.library/Cause() which will cause a software interrupt. This is somewhat of a misnomer on the Amiga1, it is really a software-initiated hardware interrupt of the lowest priority. This means that the code you add here will actually run as a genuine interrupt, interrupting any hung tasks.
Does it work?
Maybe, Not always, I don't know. Three accurate answers. Let's examine a statement from your question:
...even if the system was completely unresponsive.
If the system is completely frozen, but the dreaded guru has not yet shown his ugly face, there is a chance that this will indeed work. The big issue is that something has to trigger the software interrupt! It can't trigger itself, like all the other interrupts. This something would be either the
trackdisk.device task, or another interrupt handler. This is where my knowledge fails me, because I can't see a direct way that a disk change could do this. The three hardware interrupts available to the disk subsystem should not be able to trigger on ejecting a disk, so someone must be polling the flags manually. That means that some sort of timer subsystem and parts of exec must be in working order, almost making the trouble of interrupt pointless.
1. Some platforms, for example the 6800-series processor have a dedicated software interrupt which is different from a hardware interrupt.