Getting stuck on G1 (but not G0) in NGC M6 remap

I'm stumped. 

I have remapped M6 to an NGC file - originally I just had it supporting manual tool changes, and that was working fine, but now I've got it configured for ATC.  It mostly works, except for one persistent issue: the very first time I do a tool change (e.g. T1 M6 in MDI) after launching LinuxCNC (and homing), it gets partway through and just... gets stuck.  The relevant section of code is below - it completes the two G53 G0 moves but then just stops and sits there indefinitely, never executing the G53 G1 (Slot tool into pocket) move.  I don't see any errors or anything noteworthy in the status or machine logs, nor anything in the console window from which I launched linuxcnc.  If I hit "STOP" and punch the tool change (e.g. T1 M6) into the MDI again, it works fine - and continues to work fine on subsequent tries, seeming to only be an issue on the very first try after launch.
Curiously, if I make that problematic Y move a G0 instead of a G1 (as seen in the commented-out line that precedes it) it works just fine even on the first try.  I'm at a loss as to what the difference is; I'd rather not stick with G0 as that's pretty aggressive when slotting tools in and out of the rack.

Just a suggestion, but would any move in G1 be looking to confirm the spindle is in motion before any G1 feeds are performed ?

That crossed my mind, and I found another post where someone was getting stuck on G1 but not G0 and in their case it turned out to be that G95 was active, which ties axis motion to spindle rotation.  That was on a lathe though - I'm on a router, so I'm only ever using G94 (which can be seen as the active feed rate mode in the list of modals in the screenshot).  I did a quick sanity check of the rest of my active modal codes and none of them jumped out at me as an issue.

Aside from the G95 special case, G1 does not generally require spindle rotation - which is further evidenced by the fact that when it gets stuck like this, I can simply hit STOP and then run M6 again and it all works fine, including the G1 moves - and it continues to work on subsequent trials as well.  There's just something different about the very first M6 after launching LinuxCNC and homing.

I think you may have read 'my' post about G0 & G1 on the lathe, as that is the issue I had.
Strangely I found that at first after pressing cycle start, the system would sit and wait at G1.
But then later when I press reset and then cycle start, it would run . I actually turned some parts like this.
All was resolved when I noticed that I had the wrong G17/G18 mode active, and also setting up the spindle synchronisation correctly.
As for the G17 etc, it was switching back to G18 unrequested because of the way I had something set up (can't remember right now)

Just a thought, if your G code routine is a sub-program out side of the main program, I wonder if you may need to add a G94 command inside of the sub prior to the G1 ?
Could you try to swap the G1 to G0 as quick experiment experiment ?

I'll try adding a G94 and see if it makes a difference, and perhaps a G17 for good measure.  As seen in the screenshot it seems to be indicating that G17 and G94 are active, but to your point maybe there's some subtlety about what modal codes apply within the subroutine versus a loaded g-code file or the MDI.

It works fine if I only use G0 everywhere.