So here, off the top of my head, is a few things that would need to be synchronized for multiplayer to run stably outside of the Union Room.
Wild/Trainer battles and their effect on the overworld
If Player A gets into a battle in tall grass (or with a Trainer), code will need to exist to alert Player B, so that attempts to talk to A fail appropriately ("DAVID is in a battle!"). Player B can still move around while A is battling, so when A finishes, he'll need to resync everything.
Problems can arise if B starts their own battle while A's is already in progress -- particularly if A finishes before B. In that case, A will need to resynchronize with B even though B is mid-battle.
So there are two approaches. Synchronization of overworld data can be made possible in the middle of a battle; only one player can be allowed into a battle at a time; or some sort of "cooperative Double Battle" mechanic can be coded, such that if one player enters a battle, the other is dragged in.
NPC OWs: movements and interactions
Movement of NPC OWs will have to be synched. This may mean a modification of the part of the game engine that handles OW behaviors ("Look around", "No Movement", etc.).
If Player A talks to an OW, and Player B attempts to talk either to A or to that OW, then a message will need to be shown for Player B ("They appear to be busy right now." or some equivalent). This is without taking the OW script itself into account...
If a player talks to an OW, the effects of that script -- applymovement, etc. -- must be synched. Running the exact same script for both players would not make sense, however (Player A talks to someone, and Player B suddenly gets asked if they want to buy an Egg by some random guy on the other side of the city). Some commands would also produce obvious issues with synchronization (warp, for example -- especially if it warps to a specific X/Y coordinate).
The solution would be to make some script commands sync, but not others. Things like weather can and must sync, whereas things like preparemsg can't. The effect is that of the two players, only the one that triggers the script runs the script -- and the commands themselves trigger synchronization of any relevant data. This could also have the beneficial effect of allowing both players to run scripts independently of each other but with synchronization, although if the scripts are contradictory (i.e. both changing the weather to different values) some issues could arise. That would be the kind of contradiction that the scripter could be trusted to avoid, I think.
Hidden items (as Signpost scripts)
If Player A picks up an item, should Player B still have access to that item on their overworld? Or should it vanish from both worlds, thereby granting a reward only to the first player to claim it?
If the latter, then code will need to track and sync all flags related to hidden items. The relevant flags -- and only the relevant flags, lest something that should not sync end up synching -- would need to be synchronized when their states change. This would produce problems when the two players connect: which set of flags should be propagated to both games?
Visible items (as Poke Ball OWs)
The same issue, but with the added problem that if the items' states are not synched, then a tile may end up being walkable to one player but not to the other.
...
I'll stop now before I give myself a headache. This idea may as well be impossible. The number of things that would need to be synchronized, managed, and carefully tracked is massive.