The main problem is going to be edge behavior. When the character is straddling the threshold of the world, it is essentially in two places at once because the engine is restricted to euclidean space.
Ideally, the world would be large enough such that when the character arrives at the edge of the world, the other 'real' edge is too far away to be involved in the current simulation. That way, duplicates that are on the other side of the world can be ignored (removed from the space at some point) and the local simulation that straddles the boundary is the only one that needs to considered. For the sake of intuitiveness, rather than considering it to 'wrap around' in this model, it might be easier to consider it as an infinitely repeating world where only a local section of it is being simulated at any one time. The appearance of wrapping would arise from tricky management of the dynamic objects: when they go inactive, store their position relative to the square world; when they become active again, put them back in the proper location relative to the geometry and player.
There is one big issue with considering it to be an infinitely repeating world in implementation: after a few worlds worth of walking, numerical precision will become very poor. So, instead of actually allowing the player to continue walking in absolute coordinates forever, maintain a margin and when the player walks out, teleport everything back to more local coordinates. For example, you could have a 3x3 set of copies of your static world. If the player walks more than halfway out into any of these copies, the character and everything else has its Position set to be in the same location relative to the center world.
If the world is small such that everything needs to be simulating at the same time, things are a bit harder. A fully correct solution would look like implementing portals. Entities straddling the barrier would have two collision shapes, each detecting contacts on one side of the portal. To get this fully correct, you would need to modify solving behavior a little bit- contact constraints for a straddling entity would be accessing one entity, but using the two collision shape transforms for determining effective mass matrices. Implementing this would require significant familiarity with how the solver and constraints work.
Another option, one step less difficult/accurate, would be to duplicate the entity and bind the two versions of itself together with a constraint. There would need to be a NoRotationJoint between the two duplicates to ensure that they maintain a similar orientation. Managing translation is a little trickier; there's no built-in constraint which is designed to maintain a fixed world space offset between the centers of two entities. Creating a specialized constraint for that would be pretty easy as far as constraints go; you wouldn't have to worry about transforming anything into local space or keeping track of jacobians (the effective mass would be just a simple scalar based on the masses of the entities). At each solver iteration, it would compare the linear velocities and apply an equal and opposite impulse to make them equal, plus a little extra force to fix any positional error that accumulates over time.
While it wouldn't be too hard to make such a specialized linear constraint, you might be able to get 90% of the way there with a NoRotationJoint and just directly setting the duplicate entity's Position and LinearVelocity to match. It won't be quite as robust as a true solver implementation, but it might be enough.
EDIT: Great work on the library by the way, it's pretty amazing!
Thanks
