As well as doubling the margins on the menu theme, so the selection bar is ridiculously tight (and, not shown here, icons overflow as they don't even fit in it), which I'm sure is a bug they shipped and will never fix rather than intentional...
Conversation
Replying to
This bug was there for so freaking long, and people were crying on FeedbackHub, reddit and forums to no avail. They only fixed it in Insider recently (not sure it will make it to 22H2), by making it light gray (on white).
1
But to my surprise, somebody did actually touch user32.dll here, and added thick black outline when you use the menu from keyboard. To match the UWP menus I guess. And so it's actually usable as you almost can't see the mouse-highlighted item.
2
It's true the graphics for new MENU_POPUPITEMKBFOCUS, enum POPUPITEMFOCUSABLESTATES, etc in vsstyle.h are in uxtheme.dll, but the old menu code, in user32.dll, still needs to newly distinguish between mouse and keyboard to choose which style it requests from uxtheme.
1
Yeah, they should but didn't. Uxtheme sets hook to detect WM_KEYDOWN messages. You may notice it's very half-assed (opening sub-menu via keyboard will not highlight it new way, using mouse after keyboard will not highlight it old way, etc)
Really? Wow, that's... maybe I should've start expecting such crude hacks from today's Microsoft.
Haha oh jesus. The OS is full of ugly hooks to work around API deficiencies the same as our own code is. Except they can change the OS and still choose this awful method… I noticed themes themselves are implemented by hooking various APIs, replacing DefWindowProc etc. too.