One use case of Vim's I often use is pasting text from another window into the editor and using . to do it many times in other places. It doesn't appear pasted text is saved into Evil's repeat ring currently.
Indeed the mouse handling is not very good at moment, so I'd put this in one category with #158. To be honest, mouse commands to currently abort recording of repeat. The main reason for this is that clicking with the mouse may move point (or even switch the current buffer). And I have no idea how to repeat a mouse click appropriately at some other position in the buffer (how should the movement of point be translated to the new position where the action is repeated?)
I found that if I use arrow keys while in insert mode, these are recorded in the repeat ring, and subsequent . basically do what I would have predicted, except for edge cases near the beginning and end of buffer. (Try in the middle of a buffer: i insert some text "aaa", stay in insert state while arrowing down a few lines, insert some text "bbb", escape. Now navigate to near the end of the buffer and do .. The minibuffer shows: "After 0 kbd macro iterations: line-move-visual: End of buffer" and I incorrectly stay in evil-insert-state.)
Perhaps the way to approach user clicks is to compute a sequece of arrow keys for reaching the new point and put those in the repeat ring. Away from the edge cases, clicking around the buffer and clicking back at the original point would effectively cancel out, as one would expect.
Both the mouse clicking and the arrow navigation would need to handle the edge cases at the beginning and end of buffer. The user might, for example, insert in the middle of the buffer, navigate (with mouse or arrow keys) a few lines down then back up, finish typing some text, then escape. Next they navigate around doing ., eventually doing so near the end of buffer, where they could be surprised if the insertion text is not inserted at the point they type . -- depending on how the solution handles the edge case.
Hm, I admit that staying in insert-state after an error is not very good, evil should switch back to the state before the repeat command. But probably to best thing is still to stop the repetition in the case of an error, i.e. edge case means error message and repeat is aborted.
The reason why cursor keys work is that they are somehow relative motions (go one character left, go one line upwards, go to beginning of current line and so on) but mouse clicks are always absolute. I have no idea what an appropriate motion would be that corresponds to the mouse click. Whitespaces or non-existing buffer positions (in both, the position where the recording happens and the position where the repeat happens) may easily confuse such computations. The only reasonable situation is the one you mentioned, when point is moved back to the original position (or even only if the mouse click does not change the position of point at all). In other situation the movement of point is highly unpredictable (in particular by the user) IMO.
Note that evil's repeat system usually works by recording a keyboard macro and replaying it on repeat. That's another situation where mouse-events are really nasty to deal with. (recording a macro in a register would have similar problems).
Btw, vim has similar problems and a simple "solution" everything before the mouse click is dropped and the recording starts again. Probably the vim people have no good solution for the mouse-click problem, too.
After all, I'm not sure if it's worth the effort (besides the back-to-origin situation). It's difficult and hard to do right (whatever "right" means). Probably most evil-users do not use the mouse that often anyway ... ;)
The latest changes should solve the middle-mouse-button issue. Could you please test if it works? (this need x-select-enable-primary set to t, which is the default in Emacs 23 but *not* in Emacs 24, afaik)