I think I managed to track down the core of this problem. Each region has a set of spatial partitions where viewer keeps track of objects in a octrees. Octree is a data structure suitable for easy sorting and finding objects in 3D space (http://en.wikipedia.org/wiki/Octree).
After a teleport the viewer shifts the origin of these spatial partitions relative to the position of the avatar. The problem arises with the fact that at the moment the shift occurs, the destination region is already created and it's octrees get shifted too. If the jump was far enough, when the objects start coming in from the new region, the viewer tries to put them into its spatial partitions, but the origin is now so far, it exceeds the maximum range of the partition.
The first stab at the solution was to disable shifting, but that causes all sorts of issues with now incorrect data being tracked inside the viewer. The second attempt was to increase a range of the octree so 4096 limit would become 16384, or 65536. But this also has problems, namely viewer crashes with the extended octree.
My candidate solution is to recreate the spatial partitions in the destination region after the agent is placed in the region, and after we detect that there has been a long jump. This has the effect of leaving the maximum range of octree unmodified which means that as far as the viewer is concerned there is nothing different in the code on both OpemSim and SL if it was a plain region crossing or "normal" distance teleport.
This means that the origin of spatial partitions would be the destination sim so the limit on teleport length is practically removed.
The issues I encountered was that the viewer would still try to update the geometry in the regions that were left behind, but due to the floating point errors at those distances would fail to place them properly inside the octree structure, and crash. Which is why I mark all objects in the regions left behind dead and that I removed the check from octree when it fails to insert an object, and just ignore it. Again this has no effect on "normal" teleports.
I'm trying to push the patch to a Bitbucket clone of Firestorm repo, bit Bitbucket is not happy with that much source it seems so I'm attaching old fashioned patch here. In case Bitbucket accepts the push, I will post the link here for easy merging.