Here's my take on this:
Gcode is defined by the NIST RS274 Standard ( 1960's ) and I think there is a European Std also.
Do the standard's define things down to the number of "decimal points" ? I don't know. There are other standards out there also.
The problem can be be summarised by asking the question:
What are the requirements of the controlling program?
If all controllers where truly standardised then there would be no need for a manual for any of them.
So a program ends up having a post processor to allow adjustment such that the receiver program,
namely the controller ( MACH, HAAS, FANUC, etc) can interpret a g-code appropriately. The controller may or may not allow for flexible a configuration. I think many companies out there want it that way. There are proprietary canned cycles out there. You often will see a note like "READ THE MACHING CENTERS MANUAL FOR SPECIFICS".
At the user level we make a dumb assumption that if it works in one it should faultlessly work in another without
the understanding or taking the time to answer the question above. Even if we knew the answer exactly the user
probably couldn't adjust for it. You get responses like. the program has a bug, or it doesn't do something correctly, or maybe it don't fit a preconceived notion of how the user thinks it should work, and "your left holding the bag".The vendor may simply answer you that "ours" is correct and it's your problem.
Thus, compatibility problems have existed for over 40 years and will continue for probably another 40 years.
Ask a vendor to change his $20,000 program for you or get rid of some quirk's on his end! Will never happen.
I don't fault Mach or any other controller program, or pass a judgement on them, but rather just say "that's life".
In the context and understanding of my long winded reply, not a problem relative to the requirement of MACH.
RICH