This is partly beyond the scope of Winit but deserves a little discussion. See also #1806 and the many prior discussions (too many to easily navigate). Also rust-windowing/keyboard-types#19

Key replaces the old VirtualKeyCode as a listing of named keys. The main difference, besides Key being much larger and based on a different standard is that Key includes Character(Str), Unidentified(NativeKey) and Dead(Option<char>) super-categories.

Categories

The W3C standard categorises "named keys" into:

1. Special keys: "unidentified"
2. Modifier keys: Alt, NumLock, ...
3. Whitespace keys (note: Key includes Space; W3C standard does not)
4. Navigation keys: arrows, home/end, page up/down
5. Editing keys: backspace, undo, paste, ..
6. UI keys: find, help, escape, ...
7. Device keys: power, brightness, ..
8. IME and composition keys
9. General-purpose function keys: F1-12 (note: Key includes up to F35), Soft1-4
10. Multimedia keys
11. Multimedia numpad keys
12. Audio keys
13. Speech keys
14. Application keys
15. Browser keys
16. Mobile phone keys
17. TV keys
18. Media controller keys

Omissions

This is a big list with a lot of categories, yet still omits some things:

• Key::Character: typed text
• Key::Dead: usually the start of a key-combo sequence
• Text editing commands requiring multiple keys: ViewUp / ViewDown, WordLeft / WordRight, Italic, Bold, Underline, Link
• Search: Find is included (under UI keys) but FindNext, FindPrevious, FindReplace are not
• Fullscreen
• Remap displays (the key laptops use to manage how to use external displays: clone, extended desktop etc.)

Related: shortcut mapping

Somehow an app needs to match combos like Ctrl+C (which could be mapped to Key::Copy) and Ctrl+Left / Alt+Left / Command+Left (which could be mapped to Key::WordLeft if this were added).

So far, I have been using a different enum for this, Command. The result: much repetition and repetitive matching, yet with many omissions.

As an alternative, I could use a much reduced Command enum like this:

enum Command {
    Key(winit::keyboard::Key),
    ViewUp,
    WordLeft,
    FindNext,
    // ...
}

Caveat: if e.g. FindNext were in the future added to Key, this enum would need a breaking change.
Caveat: values like Command::Key(Key::Find) have long names making matching tedious.

Questions

Should Key categorise its values? If so, some values could be shared with the PhysicalKey enum, and some key mapping operations may be easier, but there isn't a large incentive to make changes here. (And a dis-incentive: matching e.g. Key::Multimedia(MultimediaKey::Open) is tedious with non-obvious category.)

Should, instead, all "named keys" be placed under another NamedKey enum?

Should Key be extended to include things like WordLeft, FindNext, Fullscreen? These are not known keys (though they almost could be), but are common UI functionality and shortcut targets.