Actually, there is no difference in grbl between using either mm or inches as your unit. In the grbl source code, every time a value is entered the code is akin to:
if (mode is inches) then value = value * mm-per-inch
The only possible difference is the implementation of the software generating the gcode. If the software rounds numbers to only 3 decimal places, regardless of the units, then it would matter. The software generating the gcode could easily use more decimal places for imperial measurements if they wanted to.
An excellent overview on the complexities of talking about this sort of thing, let alone implementing it is:
FWIW, I wish that there was a program which did all this math in integers using the smallest possible distance which Grbl can differentiate (or half, or one-eighth, or one-tenth that).
It doesn’t matter that GRBL is converting inches to metric and then using the metric values. If you are starting in inches, and then you multiply by 25.4, it is impossible to end up with values as precise as if you started with metric.
Here is a contrived example. Let us say that numbers in GRBL can hold 2 decimal places. The smallest possible metric value is 0.01, which is 0.01 mm.
The smallest possible imperial value is also 0.01. Converting to metric, you get 0.25 mm. You can’t specify a value in imperial that would end up any smaller than that, since you are limited by the precision of the original imperial measurement.
Luckily, computer software doesn’t usually work on the idea of a fixed number of decimal places (at least it hasn’t in a long, long, long time). GRBL uses the C type “float” for all of its coordinate positions. A float is basically:
xxxx * 10^ yyyy
For example, the number 100.01 would be represented as 10001 * 10^-2 (10001 divided by 100). So, if you were to to have 0.0254mm and 0.01inch they would both be internally represented as 254 * 10^-4. The unit used to express that same number is irrelevant.
Good link, @WillAdams. If you really want to have fun, wrap your brain around the fact that every time you perform a floating point operation there is a small percentage error in the computation. In that way x * x * x * x * x …one hundred times… * x could actually be much worse than computing x^100 even though they are conceptually the same thing because the errors compound operation over operation.