One common issue with menu list UIs is that they're "too precise", which leads to common issues like this (see the video/pic at the bottom):
You open a menu, then move slightly diagonally to select its element (partically because it's hard to move "absolutely vertically", partically because you might be visually drawn to some picture in that line and move you mouse towards that), but then accidentally cover a pixel or so of another menu for a tiny fraction of a second, and then you instead select that other menu (the video recording is a bit more pronounced, but the issue happens even with tiny hover overlaps)
There is an "affordance" (the name of which I forgot) solution for this in UI design, where some mouse movement parameters are taken into account (speed? relative vertical vs horizontal distance) and this doesn't happen - you get to the desired destination even if you momentarily hover over another horizontal menu
So it would great if DOpus added this old UI navigation improvement idea
You're moving over another menu on the way down to the menu.
We could change how this works, but then flicking through adjacent menus would have to be delayed for every menu you open, which might be more annoying than having to move the mouse down after opening a menu.
but then flicking through adjacent menus would have to be delayed for every menu
Not necessarily, for example, in flicking through adjacent menu the movement gradient is mostly horizontal, so even before the mouse starts hovering over the next horizontal menu you have enough information to determine that the mouse is not moving to a potentially opened submenu item below
But also you could expose the delay as a config to see which timing works for you and which imperfection annoys you more
