Mouse Pointer spontaneously changes to Follow VO Cursor

I’m about to open a feedback report. But I thought I’d throw this dog out to the community and see if anyone besides me wants to give it a kick. How many other MacOS users have been bitten by this? How frequently does it happen? Please chime in. I recall Mr. Grieves has ran into this. Others?

If you have MousePointer set to Ignores VoiceOver curser, as many of us do, sometimes it spontaneously and inexplicably switches from Ignores VoiceOver Cursor to Follows VoiceOver Cursor. This setting is in VO Utility, Navigation, Mouse Pointer.

This causes a subtle change in desktop behavior. Typically, the user observes that menu behavior has changed for no apparent reason.

As an example, when Mouse Pointer is set to Ignores VoiceOver Cursor, the system menubar behaves as follows:
* Press Control+F2 or VO+M to move to the menubar.
* Press F. VoiceOver focus jumps to the File menu.
However, when Mouse Pointer spontaneously switches to Follows VoiceOver Cursor, the behavior changes to the following:
* Press Control+F2 or VO+M to move to the menubar.
* Press F. VoiceOver focus jumps to Force Quit on the Apple menu.

Behavior in other app menus also changes. As an example, the context menu in Google Drive becomes unusable when Mouse Pointer is set to Follows VoiceOver cursor.

I don’t know what triggers the change. For years, I have suspected that I’m inadvertently pressing some key combination that changes the Mouse Pointer setting. But as near as I can tell, there is no VoiceOver command to change the Mouse Pointer behavior setting, let alone a keyboard shortcut. My conclusion is that this setting becomes corrupted due to some defect in VoiceOver. But I have never been able to determine a reproducer case. Days go by with everything working normally. Then, one day, menus don’t behave as expected, and I open VO Utility and find that the Mouse Pointer behavior has changed to Follows all by itself. I set it back to Ignores, and everything works fine again.

This might seem like a low priority issue with a trivial workaround. That’s not the case. There is nothing about the change in behavior that would give a blind user any kind of clue about what has gone wrong. Users are at a complete loss as to how to fix it. It impacts productivity dramatically until they stumble onto some AppleVis post that gives them a hint about what has broken.