Yeah, sure, wear-out is a thing, but it's three months old, the problem's been there since it was bought new.
So statistically, lower probability of a wear-out, though still fully possible, bath-tub curve and all that.
As it still could be a bad wire or contact, I'm testing it on a Windows machine, to see if it is the mouse or the interaction with the Micromys V5 that is the issue.
I can build a PS/2 connector test jig to test the idea of a wire being disconnected or high resistance at power-up,
and we should see a similar 'odd' behaviour, though I can't imagine such a mechanism.
That doesn't mean that all of reality is within the scope of my imagination. Testing is better.
Right now...I'm thinking:
Either this mouse is very sensitive to the PS/2 supply voltage requirement of +4.5V <> +5.5V
It's cord is extra thin, so it may suffer meaningful voltage loss over 30AWG wires and the Amiga's 4.7R internal resistance.
So maybe it's not POR'ing correctly ?
Or...
It 'needs something' at power-on \ initialization that it's not getting from Micromys V5.
and as a result it's sending back data that makes no sense, or is not synchronizing with the Micromys V5.
Found someone online talking about the trouble they have had with ensuring that their PS/2 mouse driver is synchronized with their mouse:
"The trick i found to fix this is to use the fact that byte 0 is supposed to have bit 3 always set. So when i receive a byte that is supposed to be #0 with bit 3 cleared, i simply discard it and assume byte 0 will come next. As long as you're on synch, this is completely transparent, and when the mouse comes out of synch, only a few events are sufficient to restore synchronization (especially fast with steady clicks)"
Not aware of what Micromys V5 does to detect and correct out of sync condition, or if it uses PS/2 mouse streaming or a different mode of operation.