Undo history weirdness; ^C drops changes without asking for confirmation

Open an existing file. For example, let's say its contents is just an "x".

Make some edit. E.g. append a "1", so that the edit buffer now contains "x1".

Undo that edit. The buffer contains "x" again.

Make some other edit. E.g. append a "2", so that it now contains "x2".

Save the file. The "Modified" label disappears, as expected.

Undo three times. The contents go through "x", "x1" and then "x" again. First the "Modified" label appears as expected, but after the third undo it disappears which is unexpected.

Press Ctrl+C. Since joe incorrectly believes that the buffer wasn't modified, it quits immediately without asking whether to save the file. This results in loss of work, since the saved file now contains "x2" whereas joe's buffers contain the original contents "x".

Maybe the bug is in the code that tries to detect whether the contents have been modified. I recall joe had such a bug ages ago.

But maybe the bug is in the undo logic. When you make a change and then undo it, you don't expect this back-and-forth change to appear in the undo history. Arguably that triple undo should stop after the first step and not go back to the "x1" state. Trying to make an undo operation itself part of the undo history is not something I recall having seen elsewhere (but maybe I just missed it), sounds like something that is very hard to design in a way that feels logical, consistent. E.g. undoing the "1" didn't place that back-n-forth change in the undo history, it was typing that subsequent "2" that placed adding the "1" and undoing it in the history. Not sure if it's intentional design (just implemented slightly incorrectly wrt. that "modified" flag), or something that joe really shouldn't try to do.