BR549; just to comment on your statement, I also dislike the idea of monitoring MACH for the purpose of controlling a lock, and for the reasons you cited.
However, I did fairly extensive testing of the servo error induced by using a Macro embedded in g-code and most of the time there was no increase. In order to get even a measurable increase in following error (obviously we are talking servo here), the acceleration had to be set up to a rather ridiculous degree which would not be used in 'real life', so by any measure, the additional following error introduced by the embedded macro method was zero in actual practice. I posted the results somewhere in this forum.
The reason I believe there was no significant error introduced in *my* case, was the combination of two factors. 1) Mach was automatically prevented from starting the next coordinated move until the M code was processed and 2) the total amount of time required to release the disk brake either occurred within the time it took mach to start execution of the subsequent move . . -or- . . . . the time to release the brake occurred somewhere within the early part of the acceleration and therefor had a negligible effect.
In a 'transparent' arrangement, the drive itself (at least the one I am playing with) changes the pin state within in a few milliseconds of new steps coming in and the instant the air valve is closed, the disk brake begins to release as the air pressure bleeds out of the cylinder. I do not have equipment to quantify this effect, but it stands to reason that whatever residual drag the lock may momentarily impart would be handled no differently by the drive than any other variable force. In practical terms the rapidly diminishing drag that might be present from the brake at the start of a move would not be different than the additional drag imposed by a heavier workpiece. These types of load are automatically accommodated by the PID scheme utilized by the servo drive.