Additional Info: You can create 14 windows max. ;) Why exactly 14, and if more/less/same on other dialogues than the export/wav/flac dialogue I don't know. ;)

The root cause here is the same as issue 0000713, namely the global keyboard hook that works in parallel to the window hierarchy and practically ignores it.
The only proper solution here, is to remove the pointless keyboard hook and implement hotkey handling in all place and contextss where it is desired via the normal KEYUP/KEYDOWN/KEYPRESS window messages, or, if not handling delivered key messages, at least handle it in the message loop synchronously via PreTranslateMessage().

Thanks for your reply. Can you please explain it again, so that a non-coder like me can understand it? :) What does "hotkey handling" mean, let alone pretranslatemessage()?

Why is that shortcut useless? No shortcut is useless if the user wants it. For one guy it's useless but for another one maybe not. ;) If the user wants the export dialogue with "U" (I don't want it myself, I just played around in OpenMPT!), then it's the users decision. Can't call that useless, really. Maybe that multiple-window-popup-thingy is typical Microsoft Windows behaviour, but I don't see that so often or at all in other programs.

Thanks for your reply. Can you please explain it again, so that a non-coder like me can understand it? :) What does "hotkey handling" mean, let alone pretranslatemessage()?

My whole comment was meant as a development analysis and remainder for us developers about how to solve this properly, so that we do not forget it.
I should have mentioned that, sorry.

Why is that shortcut useless?

Same thing here. I meant that it is implemented the wrong way internally, not that keyboard shortcuts are anywhere near useless in general.

No shortcut is useless if the user wants it. For one guy it's useless but for another one maybe not. ;) If the user wants the export dialogue with "U" (I don't want it myself, I just played around in OpenMPT!), then it's the users decision. Can't call that useless, really. Maybe that multiple-window-popup-thingy is typical Microsoft Windows behaviour, but I don't see that so often or at all in other programs.

Your bug report is totally valid. I did not mean to question that ;-).

Sorry for the confusion caused.

For the time being, we can disable the keyboard handler while the dialog is open, as it is already done with various other dialogs where it's not desired.

@manx, hehe, no problem, and no harm done. :)
@Saga Musix: Sounds good then, for the time being.

By the way @manx, I don't think that issue 0000713 is necessarily the culprit here. The fact that certain keyboard shortcuts work in all contexts is certainly intentional, but for some other shortcuts it is of course... less practical that this happens. For example, it can be handy to have play/stop/etc. available also while a child window is focused. Maybe we need to specially flag shortcuts which should only be usable when the main window is focussed instead of adding workarounds each and every dialog that has such a shortcut.

Issue 0000713 is certainly related, as we are recursively entering the Keyboard Hook here. And that should never happen, ever, because it can totally confuse all state handling logic (this is not directly applicable to this issue, but think about the following situation: some complex logic like module cleanup spawns some confirmation dialog while in the process of modifying module data, and some other action gets launched via shortcut in the middle). If the keyboard hook was to send keypress messages to the GUI thread's message loop, one would handle the shortcuts where appropriate automatically, i.e. the main window handler would invoke the Export dialog, and if a modal dialog is already shown above the main window, the message would not even be processed by the main window, automatically resolving the superfluous window opening.
In any case, some flags for each and every shortcut determining where it can be available is probably due in any sensible solution, even if the async keyboard hook does not go away yet. In particular, anything that spawns dialogs probably needs some flag, as those are the most problematic here.

Should be fixed in r6908, which should be on https://buildbot.openmpt.org/builds/ soon.