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.

I may be wrong, but it seems because of the G1, it's looking for proof of spindle rotation before it can progress?
Do you have the 'spindle at speed' pin set up in the HAL file ?

Alright, after an absurd amount of banging my head against the wall with this, I finally got past it.
I tried the various ideas here, and anything else I could think of, and nothing made a difference.

It turned out to be something more bizarre.  I have an M200 NGC subroutine set up which uses an optical sensor to check the presence of a toolholder in the ATC spindle, since the spindle has no built-in sensor.  I have it run M200 after the built-in homing routine, so it homes and then immediately runs this check.  As part of that M200 routine, I run the spindle at low speed with an S500 M4 command.
By extensive trial and error, I finally found that if I commented out that one line (so M200 doesn't run the spindle) then this issue with G1 vanishes.
I still have no idea why running the spindle in an M200 after homing should have any effect on the ability to do a G1 move (as part of an M6 routine or via MDI) quite a while later...  But spindle rotation isn't critical to my M200 routine so I can live without it as a workaround.