John,
I guess that the most basic logic of the standard set of Gcodes is what we would all try to adhere to, in order to have some uniformity and compatability with all other machine tools, and cadcam programs that are designed to output and to read standard ISO nc code programs (in order to do a backplot, for example, G00, G01, G02, G03 must mean the same thing to everyone).
But, when it comes down to the way that your particular machine operates when a given Gcode number is used, that is up to us to configure and optimize in Camsoft's gui. That is what I absolutely love about the PC based cnc system such as this.
For example, you may have noticed a problem if you forget to program a feedrate when running a program that you create right at the control. With the standard G01 logic, I believe the control just kind of "hangs" because the motors take a really long time to get somewhere at zero feedrate
So in an example such as this, it is a simple matter to add logic to the G01 to tell the operator that he forgot to program a feedrate, and to auto-abort the current nc program. This "extra logic" is not part of the meaning of a standard G01, but is nonetheless, is a valuable convenience to have in place for the operator's sake.
There are also lots of "empty gcode slots", for which, as far as I know, there is no recognised standard of programming. For those who like macro type operations, this is a great asset to be able to make up their own special routines, that fit the type of work that is common in their shop. You probably have seen many of these as examples in the various Camsoft cbk files.
And don't get me started on how exciting it was to develop my own G81, G83 cycles, and G33 lathe threading cycles. There are simply limitless tweaks and improvements to be made (depending on your imagination and ability to write logic), yet still, the net result of that particular gcode still would be the production of holes or threads, or whatever, just like the standard gcode intends to see happen.