This is exactly like the MC-13024 "bug", which was closed for being "invalid". However the "invalid" verdict is in itself not valid at all. See below!

Yes, I can confirm that this is occuring "mostly" because of some optical mouses.

BUT!

The statement that "this is not a Minecraft issue" is invalid because: (please read fully, detailed bug behavior explained after why this should be fixed)

For any input type, wether it is keyboard or mouse, any software should definitely check for its desired "valid range" of input values, and accordingly adjust the input to let through only good data likely to produce desired results. Undesirable input, especially known sources of bad input from users or independent third-party, should in all cases either be prevented or modulated.

If Microsoft Windows was coded using the "this is a mouse input issue, not a Windows issue", then the same kind of thing would also occur, at the same kind of frequency, on the Windows desktop, and we'd get wild mouse pointer mouvements because Windows would stupidly "simply follow suit", believing that all input from the mouse hardware "is and should be perfect".

If all other freaking games were also coded using that same "philosophy", then all of those other games would ALSO give seizure-inducing wild spinning because of overly-sensitive hardware. Most games don't, which is proof enough that the professionnal game makers actually do see this as something that needs to be adressed.

If sound systems and cell phones were designed with the same "philosohy", then users would constantly hear constant noisy scratches and interference-like white noises coming from such devices, because the software designers thought that simply taking the input directly and for granted, without trying to filter it at all, and then put the fault of bad sound on the bad microphones hardware of the other cell phone companies, or a bad connection, was a sufficient reason.

If passenger airplanes and jet planes were designed in this manner, thousands would die each year because, when the pilot does a "bad manoeuver", instead of refusing or modulating the input to within the plane's tolerance levels, the plane would simply wildly try to "follow suit" doing impossible moves, and then of course something would break and the plane would crash and burn. And then trying to say "But it's not the fault of the plane, it was the fault of the pilot!" just wouldn't cut it, wouldnt it?

Forgetting to filter input to within playable levels is a bug, in the very same sense that "assuming" that a variable "should" fall within a range of values normally going from X to Y, and then seeing the game crash because, of course, the coders deliberately dismissed that there are in-game ways to make that variable go outside of that "valid" range anyway, will also end up causing bugs. This wild spin is just that: one more of those bugs caused by failing to predict and to deal with invalid input value ranges.

And this bug here occurs QUITE OFTEN ENOUGH. I suffer from it wildly and all the time, in fact every few minutes of play, major annoyance all around. Sometimes it lasts for several seconds or even FOREVER SPINNING UNTIL I MOVE MY MOUSE AGAIN.

It happens more to some mouses, especially optical mouses and other very sensitive input devices. In the case of an optical mouse it is caused by the mouse being moved ever so slightly "off the surface" on one side (front, back, or actual mouse sides), thus making the laser go "off" it's right range of values and maybe output "infinite or division by zero" values. Or something way beyond the normal range. Only the tiniest fraction of a millimeter is needed to cause this. and the way a user holds his mouse will have a great impact on the frequency of this happening, so it's not just the mouse hardware it's also the way the user holds his input device when playing games.

In short, this is simply a signal spike of some sort. SIMPLE TO DETECT. This is what causes all those input devices to send off wild input signals, and Minecraft stupidly chooses to simply "follow suit" with that grossly bad input data.

The game should EASILY be able to tell when the player movement is a wild spin for seemingly no reason at all, and prevent it altogether.

It happens a LOT more when moving the mouse towards looking up or down. In those directions, the tiniest mouse movement can generate a LOT of on-screen movement. Something feels just plain WRONG with the way Minecraft handles mouse movement in those directions.

Seemingly, Minecraft just forgets to poll the mouse again until the next "true" mouse movement event. That is why this glitch can occur for seemingly LONG times. If an input data "spike" occurs right before the mouse stops moving, then you're in it again for a wild spin again, ether looking straight up or down (but even sometimes at eye level too).

If Minecraft did this polling check (not a few times per second but actually tens of times per second - either as fast as the mouse hardware allows or at least tring to check twice as fast as a good human reaction time, because the mouse is a critical input stream and should be treated as such), then Minecraft would easily be able to take note of when such "wild input" becomes brief spikes that fall completely out of the mouse acceleration input value from "right before", flag it, and if in the next few instants the spike is confirmed as such (the acceleration not position values just as suddenly return to within near their previous range), then it would be able to correct what the hardware failed to do and return the view to what it would have been without the spike, with only a "normal" amound of rotation instead of always getting a super-fast wild spin.

And by polling frequently using mouse acceleration instead of position, Minecraft would also be able to STOP any spinning, too, as soon as the mouse would become immobile again. Currenty, it is unable to do so, how can you not see that as a bug is beyond me.

Windows does this filtering.
All other games do it too.
DVDs do it between reading the signal from the DVD and transmitting the image to a TV screen.
Sound systems and mobile phones do it between getting the sound from the airwaves before sending the sound to their speakers.
It is also done for plane control to avoid pilot errors.
etc.!

It is called [ Noise Filtering ] and is an elementary coding practice. Failing to do it is a buggy behavior, definitely not a feature "working as intended"!