"Managing Focus Within Components Using a Roving tabindex" https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_roving_tabindex is currently fully based on the assumption that a user is just navigating via the keyboard. Hover, if just following the steps there, users that interact with a component with the mouse or with non-kbd AT (like touch+AT scenarios) and who then switch to using keyboard will find a mismatch of what they've activated previously, and what still has focus.

Not formulated a full plan on this, but something in that section should also make reference to also listening to things like click events (regardless of what the tabindex on those child elements is), and doing the tabindex switcheroo even as a result of click (so that the roving tabindex matches whatever the user has activated/clicked directly with mouse/touch+AT/etc), so that the interface state remains consistent - otherwise there may be a weird scenario where the user clicked and actually selected one thing with the mouse for instance, but tabindex on that element is still -1