Registered Shortcuts: unexpected processing behavior within Dialog / Notification combination, if they registered the same shortcut key

[netsrotr]

Description

We use the same Key to register a shortcut for a button (escape key) within a Vaadin Dialog (to dismiss the dialog) and also for a error Notification (again, a button with shortcut escape key to dismiss the notification). That notification gets displayed by the dialog. Now, if a user press escape while the notification is still visible, the key is processed by the the notification as expected (and close the notification), but also triggers the handling within the parent dialog (that show an Unsaved changes)!
This double processing is not expected.

Expected outcome

The escape key should only processed by the topmost overlay, in that case the notifiaction instance, and not also by the dialog that is stacked behind the notification.

Minimal reproducible example

See the attached sample:
shortcut-handling-flow-spring-24.zip

Steps to reproduce

1. Start the project
2. Press the one only button to open an editor
3. Press the space key inside the text field
4. Press the escape key (watch the log within your IDE)
5. Press the Save button displayed in the dialog. A error notification is displayed
6. Press the escape key again to dismiss the notification (watch the log within your IDE.
   Note the additional LOG entries generated by Vaadin)
7. Now you are at the stage, we classify as an issue:
   the escape key does not only close the notification as expected,
   but also trigger to show the Unsaved changes again! This is not expected.
8. That behavior is equal, unrelated to the used dialog implementation to confirm Unsaved changes:
   if you uncomment the line within MainView::handleCancel(boolean) to use the vaadin ConfirmDialog,
   there is no difference related to escape key handling.

We can go around the issue, if we implement also our own notification variant e.g. using the Vaadin Dialog component
to provide a modal version of a notification, but what is the Vaadin framework used to be for, if we have to re-implement
all this basic stuff again by our own?

A real Vaadin window manager considering Dialog/Popover/Tooltip/Vaadin messaging (Server disconnect...) and all components using overlays that manage the stacking order (z-index), modality, focus handling for non-modal dialogs
would be really a great improvement within the Vaadin Flow framework component context.

Environment

Vaadin version(s): 24.5.4, 24.5.5
OS: Windows

Browsers

Chrome