The issue title is pun intended, but it really happens 😆.
To trigger the halt sequence, press the decision key with the dog or with the door. After some dog advice and a transition, the door will be opened and a dog will say a "Stop!" message and interpreter halts. Some dogs should appear and start a battle instead. Earlier master versions were working there, so this is a regression.
When a event that is "Waiting" collides with another event the wait timer reduces faster (depending on how many are colliding), so when one collides the wait countdown is twice as fast.
Here's the explanation: In the map 21 (The Gate Open2), the event EV0004 tries each frame to walk where EV0005 is. The move route of EV0004 is skippable. EV0005 has a parallel event with a ProceedWithMovement.
In EasyRPG, EV0004 tries to walk where EV0005 is. Because of #884, EV0005 runs its interpreter early, executes ProceedWithMovement and, because EV0004 is still moving, doesn't continue. After that, EV0004's movement fail. Because it's a skippable move route, the move route ends.
In RPG_RT, things go the same way but after all that, EV0005's interpreter gets updated a second time. This time, EV0004 doesn't have an overwritten move route, so it passes the ProceedWithMovement command.
I'm not sure in what circumstances does an event get update twice.
In the meanwhile we know that it's the collision which causes this behaviour.
As a notice for the laaaaaaaate future when the editor is ready: The Player should offer for EasyRPG games a "Engine: EasyRPG" mode which does not emulate such bugs. ;)
Use wait_count for waiting Pan Screen commands
For better compatibility with original save games and to reproduce correctly the behaviour of RPG_RT in the rare case of a parallel event running a waiting Pan Screen while other events walks against it (like in the cutscene of #937).
Run parallel interpreter and move route on each collision