Maybe also affected by this issue (see description)?

[dinkumoil]

The Pythonscript plugin had an issue with menu entries created by the plugin itself, see here. This issue was eliminated by introducing a new Npp event, see here. This event is available since Npp v7.5.9.

I guess NppExec could also be affected.

[d0vgan]

Yes, NppExec is also affected by this.
Indeed, the NPPM_REMOVESHORTCUTBYCMDID needs to be used.

[d0vgan]

Well, an internal array of menu item ids for NppExec's scripts can be introduced, and the menu items listed in NppExec's Advanced Options can internally be associated with the menu item ids.
It will help in case of menu item deletion.
In case of menu items moving (up or down), however, I have no idea what to do. It does not look like NPPM_REMOVESHORTCUTBYCMDID helps here.
In general, all this situation does not look good to me. Currently, a plugin's internal logic does not deal with (and had no knowledge of) its menu item ids, so NPPM_REMOVESHORTCUTBYCMDID or similar is not an obvious way anyway.

[chcg]

@d0vgan Are you talking about to modify the shortcut from within a nppexec script?
This is not done by PS, the user has to do it manually under Settings->Shortcut mapper -> Plugin commands. And a new entry is just available after a N++ restart.

For user changes via the n++ menu there is NPPN_SHORTCUTREMAPPED, which is already implemented by your plugin as far as I see.

Pythonscript could remove menu items calling python scripts in a setting menu and if a shortcut is assigned to that menu item it is also removed automatically.

[d0vgan]

NppExec's Advanced Options additionally contains the following two buttons: [Move up] and [Move down].
Now imagine that the menu items being moved (one of them is moved down and another one is moved up) already have their shortcut keys. From NppExec's perspective, absolutely nothing is changed with regard to shortcut keys (because NppExec itself is just not aware of shortcut keys) of the corresponding menu items. However, from Notepad++'es perspective, the two menu items are switched whereas their corresponding shortcut keys are still mapped to the old menu item positions, not to items themselves. Saying the same in other words, this leads to the shortcut keys to become switched. Let me "illustrate" this:

Initial Position:
Menu Item A - Shortcut A
Menu Item B - Shortcut B

Position after moving the items:
Menu Item B - Shortcut A
Menu Item A - Shortcut B

And I have no idea how this can be fixed, because NPPM_REMOVESHORTCUTBYCMDID does not allow to deal with it - because the item is moved (its position is changed) rather than deleted.
That is why I'm saying that NPPM_REMOVESHORTCUTBYCMDID is not enough to deal with it and, moreover, it adds additional complication to plugins because now the plugin's code must be aware of the menu items positions (created by the plugin) and their associated shortcut keys. Currently NppExec does neither of both: it does not store the association between the scripts and their corresponding menu item positions, as well as it does not store the association between the scripts and their shortcut keys for the corresponding menu items.

[chcg]

NPPM_REMOVESHORTCUTBYCMDID can't help with that. You would need a new callback to modify the shortcut <-> menu item mapping at n++ shortcut code.

[d0vgan]

I was thinking about this issue again and again, and here is my conclusion: the proposed approach with NPPM_REMOVESHORTCUTBYCMDID is a completely wrong direction.
Here is why.
The source of a problem is not in plugins, it's in Notepad++ itself. Here is what I mean: the origin, the cause of the problem comes from the way how Notepad++ stores shortcuts for the plugins. Notepad++ maps the shortcut keys to the value of internalID that is not e.g. a unique hash of plugin's menu item name, but something like a menu item's position. Obviously, when this position is changed, the mappings between these positions and shortcuts becomes wrong.
Now I'm asking a question: is it a plugin's fault? What if Notepad++ stored some unique hash keys to identify plugin's menu items disregarding the menu items' positions, would we face this problem?
And, by introducing NPPM_REMOVESHORTCUTBYCMDID , aren't we in fact trying to fix Notepad++'es internal issue in an external plugin's code? Isn't it strange?
Moreover, as it was discussed here, anyway some different fix is needed to deal with moving (not deleting) of menu items.
So my proposal is to fix it in Notepad++ itself: do it once, and for all the plugins.