A keyboard shortcut that never fired, and why
Shift plus a punctuation key looks like any other menu shortcut. AppKit disagrees.
Two of Lumeira's shortcuts, ⇧⌘[ and ⇧⌘] for first and last sibling folder, had never worked. Nobody noticed because nobody uses them, which is its own lesson. We found out while adding the ? shortcut for the help panel, which also did nothing.
What was happening
On macOS, a menu item's shortcut is a character plus a set of modifier flags. We registered / with the shift flag, which is exactly what the user types.
AppKit matches shortcuts against the key event's characters ignoring modifiers. The catch is that "ignoring modifiers" does not ignore shift. Shift plus / arrives as ?. So the menu is looking for / with shift held, the event says ? with shift held, and nothing matches. Ever.
Letters do not have this problem. Shift plus f arrives as f uppercase and AppKit handles the case. Punctuation is the only place it bites.
The fix
Register the shifted character with no shift flag. ? alone, not / plus shift. { with command, not [ with command and shift. Lumeira's binding layer now has a small table for the punctuation keys that have a shifted form and does this translation when it builds the menu.
How we checked without a screenshot
The accessibility API will tell you what a menu item actually registered. Before the fix, the help item reported / with the shift modifier. After, it reported ? with none. That read-out is a better test than pressing the key and squinting.
If you build Mac apps with user-configurable shortcuts, this one is worth knowing. It only shows up when a user picks a shifted punctuation key, which is rare enough that it can sit in a codebase for years.