Definitely a good idea, not sure if we'd even need an option for it. It's how undo/redo works almost anywhere, after all.

The biggest question I see here is actions that span multiple cells. For example you make a 10x10 selection and delete its contents, then undo that. Just pointing the cursor to the upper-right corner of the selection would be weird, because maybe that deletion only removed a single note in the center of the selection. Should the whole selection be restored, not just the cursor? (practically cursor and selection are the same thing in OpenMPT, so it's not a question of technical feasibility.)

The only problem I see is some people won't like it due to jumping cancelling selections. I believe a toggle would be the best way to implement it considering how long it's been this way. Alternatively, the feature could have a toggle that determines if, when a selection is active, whether undoing or redoing moves the cursor or not.

To answer your question, though, other software usually reselects the affected portion so I do believe that's most intuitive.

Okay, one technical detail that would be quite relevant to this feature that is missing is that the undo buffer keeps no record of individual columns within a pattern cell; i.e. it doesn't know
that your cursor was placed in the volum column, so the smallest possible unit it can currently set the cursor to is a full cell (note column to parameter column). We would have to keep a copy of the entire cursor state with each undo step in addition to what we already have, so that makes the request more complex to implement.

I figured out a possible way of implementing it. You don't necessarily need to know what column was selected, actually; you can simply look at what type of action was undone and discern which columns were selected by the actual edits that took place. Only problem I see is "Clear Selection" doesn't give specifics in Edit>Undo which seems to imply it only knows a selection was cleared but not what was cleared; though I can't say for sure, because that doesn't make a lot of sense (it still has to put the data back when undoing, after all).

I guess that might look reasonable for many interactions; but it might also feel weird for others. Let's say you cut a 5x5 region in the pattern, but only a single cell in that region contained any data. That 5x5 selection is still present after cutting, and now you decide to undo the action. The selection is now reduced to that single cell, if I understand your idea correctly. That doesn't feel quite right to me, and it's also not what other applications do. But maybe better than nothing.

From what I can tell, OpenMPT's undo counts data as modified even if nothing was changed, and even if the command had no effect on that particular column(ie, inputting a transposition on the Volume column), right? Therefore, the type of modification would determine the columns selected, and the row count would be determine by looking at the number of rows modified, regardless of if anything changed.

...Actually in general, you wouldn't need to keep a record of the cursor state at all; the cursor's position should always correspond to whatever data has been modified in that undo step, because in order to do anything to a selection, your cursor has to be at that position.

I still think a toggle would be nice, of course. I think there would definitely be people who prefer undo not messing with the cursor position. And in fact (if it's not too much to ask) a separate keyboard shortcut for "Undo and move cursor" or something would further improve this in case you're quickly undoing a bunch of stuff you know the location of and don't want to mess with your selection. I could see that being helpful in one hour competitions.

EDIT: Messing around selecting stuff reminded me that the cursor could be at the top or bottom of a selection depending on the direction you went. Still, I think the top of the selection should be preferred as it allows you to play that sequence of notes from the cursor position.

From what I can tell, OpenMPT's undo counts data as modified even if nothing was changed, and even if the command had no effect on that particular column(ie, inputting a transposition on the Volume column), right?

The undo/redo system isn't really aware if anything was changed at all - all that Undo does is taking a snapshot of a specified part of the pattern before the actual pattern modification is carried out. Some commands do check if any actual changes were made, in which case they immediately remove that undo step again. The undo system itself is pretty dumb - all it knows is what the area of interest looked like before the modification.

...Actually in general, you wouldn't need to keep a record of the cursor state at all; the cursor's position should always correspond to whatever data has been modified in that undo step, because in order to do anything to a selection, your cursor has to be at that position.

For single-cell edits, that is true - but the pattern cursor and pattern selections are the exact same thing in OpenMPT, so not only would just keeping track of the last cursor position feel half-baked, it would actually feel off if undoing would only ever restore, say, the upper-left corner of the previous selection. There are also edge cases where modifications might happen outside of the selected area - think of chord entry, for example, where up to four notes are entered, but only the cell containing the first note is of course selected at the time of entry. And then there's MIDI recording, which - apart from the current row - doesn't need to coincide with where the edit cursor is placed at all. Same with automatic recording of note-off events during live recording.

I guess what I'm trying to say is that there is no one-size-fits-all solution. For most commands, it will be fine to restore the previous selection rectangle (which, as a reminder, is equal to the edit cursor in case there is no selection), however exceptions might have to be made for MIDI (either the cursor is enforced to the MIDI data entry location, or the cursor is not moved at all) and chord entry (maybe extend the selection to all notes), and of course any other actions I cannot think of right now.

I do have a prototype which restores the previous selection for most commands, but it has no special handling for the aforementioned cases yet.