I messed up a bit both with the example given and the code, although the general concern might still stand if you are using Plugins that work on the map.
The concern was that while $gameMap and other game objects get replaced, your are in the middle of the old $gameMaps update function when that happens, meaning the rest of that function call will still use "this" to access the old map. The old maps events will still get executed, but calls to game objects will work on the newly loaded objects
(during passability checks for example).
I was indeed wrong with the example of the parallel event changing a variable though, thanks for pointing it out. =) That makes it indeed less likely to cause chaos. ^^
Sorry for that.
The "Switch On/Off..." move route commands might still interfere with a newly loaded savestate. Not sure who actually uses that command though...^^
And yeah, the code I posted...

The code was way too long to fit in a script command anyway it turned out.
I had to stealthily fix the "
this.popScene()" to "
if (!SceneManager.isSceneChanging()) this.popScene()" so you might have seen the even more wrong version...^^
The purpose was just to have a fallback should loading the game fail and the
SceneManager.goto(Scene_Map) line never get executed.
The idea of the changes was to let Scene_Map complete all its updates for the frame just in case before changing to the handcrafted scene to load a new game. Unfortunately it was obvious I didn't try to test that thing first...^^
May do another proposal on that later if nobody else does. :)