Doing the sitesearch and event tracking upfront actually caused the problems. At that point the forced date time was not yet set. So the date time from the previous iteration was used. For the first iteration of a userid that means it used the date time from the last iteration from the previous user id.

So the first iteration of userid3 inserted a visit for e.g. '2010-02-20' for the event tracking and sitesearch, but the pageview below was than inserted for '2010-02-01'. Each iteration then forces a new visit to be inserted. So a couple iterations later a second visit for '2010-02-20' with the exact same time will be inserted. The next iteration then tracks the sitesearch and event. To map those actions to the correct visit the tracker tries to load the visit to increase the action counters. But there are now two visits with the exact same parameters (idvisitor, user_id, visit_last_action_time, ...), so it's actually up to the database to decide which of the records to return first. That behavior changed due to the new index, as that seems to have changed the order in which the records are returned.

As this is actually only a very test specific issue, that won't occur while normal tracking, I've adjusted the tracking to be a bit more realistic and avoid duplicate visit entries...