It might be related to the TrackPopupMenu on notification tray workaround, where one must set themselves to the foreground window and post WM_NULL or other mess

It might be related to the TrackPopupMenu on notification tray workaround, where one must set themselves to the foreground window and post WM_NULL or other message in order for the window to be properly dismissed. However that one in particular iirc has to do with the way input is handled among threads, and how Windows is careful with how activation / focus gets passed among processes. Since the taskbar needs to do various things without taking input focus or capturing the mouse etc, I would assume the bug has to do with managing this obscure behavior, and missing a notification (or some obscure race condition?) that results in the taskbar not transitioning to the non-hover state. Outside the taskbar you can often see these bugs in situations such as click, hold the mouse, then move outside of the window or have focus switched. Many times the capturechanged events or activation events do not end up handled properly -- trying to do all this without capturing the mouse or input is even more difficult, though I presume a simple timer would suffice.