I think the return thing is a classic issue of autocomplete systems: what do you do if the user hits return (or decides to) and some characters are not yet reflected in the UI showing the current suggestion? Whatever you do there'll be misunderstandings.
I have a fairly high typing accuracy on physical keyboards, in particular when I'm in a focused state, so I actually don't double-check editor commands most of the time -- I let them fail, which happens rarely, and only double-check them the second time.
And yes, in practice I use shortcuts mostly (although either vim extension shortcuts or custom ones, usually, because many shortcut don't work as is in the vim extension, so the command palette hint is useless to me as well - but I don't hold vscode responsible for that).
It's a classic issue of slow autocomplete systems, why should there be any perceptible delay for such tiny data sets?
If you don't double check, it's most likely that you use it for something you're certain about, so it's more like a key chord rather than a search bar? In that case for these frequent commands it might make sense to add those unique symbols/letter combos (some extra Unicode symbols can help here) so that the fuzzy algo will never trip
And not showing currently active shortcut for a palette command is just another bad UI implementation, that kind of info should be centralized/anyways up-to-date so you can use it in palettes or menus or what not
I have a fairly high typing accuracy on physical keyboards, in particular when I'm in a focused state, so I actually don't double-check editor commands most of the time -- I let them fail, which happens rarely, and only double-check them the second time.
And yes, in practice I use shortcuts mostly (although either vim extension shortcuts or custom ones, usually, because many shortcut don't work as is in the vim extension, so the command palette hint is useless to me as well - but I don't hold vscode responsible for that).