If you're using packetflow with non-instanced zones enabled it can cause fastfollow to warp following characters to the middle of the zone pretty consistently.
Have not seen it as much with packetflow enabled only for instanced zones.
If I had to take a guess at cause here, it's because the outgoing packet event triggers when the leader sends a 'request zone' packet, and tells the followers to send the packet with no verification or throttling. If the leader does not receive a response from the server in time, the legitimate client will send the 'request zone' a second time with the same sequence bytes.
Because the sequence bytes are the same, the server recognizes it as a duplicate and doesn't process it, but the addon still does. Since the addon is now telling the follower to zone twice, the follower sends two 'request zone' packets, but does not match sequence bytes, so they count as 2 seperate requests. This causes the server to double process the zone request.
Because the second zone request can be processed from the new zone, this can cause sporadic results depending on the state of zoning. The new zone will not use the same params as the old zone did, so your zone request params are inaccurate. With packetflow, you're more likely to be fully into the zone to catch the results of the second response and get flung, but you're probably still being flung on server side either way(it just puts you back before you load in more often without packetflow).
I do not think this can be made safe with a small patch to the zone request logic. You can reduce the frequency but frankly, you should not be force sending the 'request zone' packets to begin with unless you have a full understanding of them. A much better way to do things would be to predict the direction you were running when you zoned and extrapolate a vector for the character to continue running toward so they zone naturally.