Note that with the current version of OpenMPT (1.30), it is possible to restore a default keybinding by deleting the custom keybinding and then restarting OpenMPT (or by saving the keybindings and immediately loading them again). And of course there is the even less elegant solution of looking up the default keys in the manual.

This auto-restore mechanism often lead to a lot of confusion though, so starting from OpenMPT 1.31 only newly added default keybindings will be added to custom keymaps after updating OpenMPT to a new version, so either way a solution to this issue has to be found. I'm not sure how useful the current behaviour of the Restore button is - if you made a mistake, you could also cancel and reopen the settings dialog, although that is also rather cumbersome, in particular if you made a lot of changes without hitting the Apply button.

A dual-function Restore button (first click: restore to previously used key, second click: restore to defaults) could help, but one think to keep in mind is that Restore works on a per-choice basis: If there are three different keybindings assigned to a shortcut, Restore only resets the currently selected one. I'm not sure if the "restore to default" behaviour is very sensible in that situation: Should it only restore the, say, second choice, if that's what was currently selected? What if there are now three bindings but the default map only had one: What happens if you hit restore on the second or third choice? What happens if the first default choice for a shortcut was Ctrl+X and the second choice was Ctrl+Y, but the custom keybindings were changed to the first choice being Ctrl+Y and the second being Ctrl+X?

I saw that ticket about removing the auto-restore option, and was glad to see it's resolved in 1.31 because that's a bit annoying too! Personally I don't mind that the key comes back per se since the main reason I unbind keys is to have a clean and understandable config file (I keep it backed up in source control), but it also is a source of surprise when you accidentally hit a key you thought you had unbound and it does something. (i.e. opposite of principle of least surprise)

You have a point about the potential for added confusion around the Restore button in a possible future state where it also restored defaults. I think the least confusing solution would be for it to only restore the default binding(s) if and only if all other bindings had been deleted for that action. This would essentially be the same behavior that you get right now if you unbind something and then restart the app and magically it's bound again, except now it would be user-controlled on a per-action basis.

As of r17973, if there are no choices configured, the Restore button now restores the default for the given shortcut. r17974 also backports this for OpenMPT 1.30. Let me know how it works for you.

Test builds should be available in a few hours from https://builds.openmpt.org/builds/

Gave the test build a run, looks good. Thanks!