Mismatch between 'Define keyboard shortcut' input and actual handling of keyboard shortcuts

Summary of the Issue
The way the 'Define keyboard shortcut' interface interprets key presses does not match how the actual Musescore UI interprets the same key presses. This directly causes various problems including those reported in #14539 and #15091 and is directly related to the request in #15820 (I will explain that later).

Full Description of the Issue
When using the 'Define keyboard shortcut' dialogue box to set a keyboard shortcut, the user presses a single key or key-chord. The representation of the captured input (which is identical to the tag in the XML file which stores the all the keyboard shortcuts that are defined) is displayed in the 'New shortcut:' field in the dialogue box.

While this input method is certainly simple for users to understand, the way the 'Define keyboard shortcut' interface interprets key presses does not match how the actual Musescore UI interprets the same key presses.

The most egregious of these is the handling of 'shifted' non-letter characters as mentioned in #14539 and #15091. The first happens because the 'Define keyboard shortcut' dialogue records shift+1 or shift+. as 1 and > respectively. This interpretation is not inherently wrong, and would actually fix some problems with non-English keyboard layouts (#15091). by serving as a keyboard layout agnostic way of specifying characters (i.e. no matter if the character is accessed directly or via shift on a keyboard, the key would activate).

However, the problem arises in the mismatch between the keyboard shortcut editor's handling and the key handling of the rest of Musescore.

Shortcuts that are set to shifted characters like !, @, >, | are not triggered when the corresponding shift+<key> chord is pressed.

Over all, because of this, 'properly-defined' default shortcuts like shift+. don't work for some non-English keyboards, while commonly redefined shortcuts, like shift+1, don't work as they get set to the shifted character, like !.

Secondarily, setting more advanced types of key shortcuts including multiple shortcuts for the same action, or sequences, is completely absent from the application.

Expected behavior
When using the 'Define keyboard shortcut' interface, the user would expect that the key or key-chord they press while setting the shortcut would trigger the desired action when actually using Musescore. E.g. holding shift while pressing 1 should be interpreted the same in both contexts.

Additionally, an advanced user would expect to be able to set any type of shortcut that Musescore can handle including multiple shortcuts for the same action, and sequences (multi-sequences as in #15820).

Workaround
As has been mentioned in various places, if you are having problems with setting keyboard shortcuts, or shortcuts not working particularly when they involve non-letter characters that would be accessed with shift on an English keyboard (e.g. shift+1 (!) or shift+. (>)), you will likely be able to solve these problems by exporting the keyboard shortcuts, editing them (by editing the XML file it exported), and then importing the edited file back into Musescore. In the case of shifted characters, make sure that all the keyboard shortcuts that were not working are expressed as shift and the un-shifted character on the same key (e.g. shift+1 instead of ! and shift+. for > on an English keyboard).

Platform information

• OS: Mainly Arch Linux, but I checked on some other distributions. I have also had the problem on both native installs (through the distribution package manager) and AppImages.

Suggested Solution
Aside from re-aligning the behavior of the 'Define keyboard shortcut' dialogue and the rest of Musescore's key handling, I think adding a simple text box where users can manually enter keyboard shortcut strings would be helpful.
It would:

1. Provide a way for users to access the more advanced features of Musescore's keyboard shortcut system without going through the hassle of exporting the keyboard shortcuts, manually editing the XML file, and re-importing it, (addressing #15820)
2. Make it possible for people who would be intimidated by the workaround process a less technical way to fix the issues like those seen in #15091 and #14539, and
3. do so without forcing that complexity onto new users like it was before Musescore4.