From the UX perspective, navigation with keyboard and mouse are 2 different type of things. Sharing the same cursor item between 2 different types of input makes bugs like https://bugs.kde.org/show_bug.cgi?id=455674 possible. But even if it get fixed, there's still a situation when user hits meta, performs a search and hits enter to run the first entry without paying attention to mouse cursor and item selected. But if mouse cursor is placed in menu area and hovers another search result, the enter buttons opens it instead of the first entry. What I'm trying to say is there's no situation in real life when it's helpful to hover search result with the mouse, but select it with enter, so hovering search result with a mouse should never select it.
I agree that there's an annoying situation where the mouse's position can cause the focus to move away from the top item when searching. With that said, the intention isn't to make it so you can hover and then press enter, it's to make it so that switching to arrow keys moves the highlight you already see instead of starting from a completely different location. I think what's happening with the search view is the animation making the search results move downwards causes an item to register a hover change. We should probably block allowing hover to change the focus until the animation is complete. This way the first item is always focused when starting or changing a search.
I think we should just fix Bug 455674; having two selection sources would be super weird and nonstandard IMO. *** This bug has been marked as a duplicate of bug 455674 ***
Maybe I wasn't correct enough with my explanation. KDE is actually the only DE that acts this way. most of DEs and operating systems just highlight item on hover and keep keyboard cursor completely separated from mouse actions. There's no 2 different cursors, there's acrually only a keyboard one and cursor hover animation. See the Gnome screenshot attached. This it pretty standard behavior and gold standard from UX perspective. In Windows it works the same way, but I can't demonstrate it, Gnome boxes don't run windows 11 unfortunately.
Created attachment 150028 [details] How it looks in Gnome
Yeah, that's two different highlight effects. If I press the return or enter key, which thing gets activated? I don't think that's a good idea at all.
Again, that's not an idea, it's a pretty standard UX thing. When you tab with keyboard over the elements, you know which one is going to be activated with enter. All apps are actually work the same way, see dolphin screenshot.
Created attachment 150074 [details] How it looks in dolphin
In Kickoff, focus control behaves like menu focus control.