@dc42 thank you for the clarification/confirmation.
I'm starting to get frustrated! I have the infill extrusion rate very consistent, except for some weird spots where the rate suddenly drops for one segment.
The odd thing is, it's dropping to the excact extrusion rate that was required from a previous slice in a previous build. The current settings all request a 0.2 mm extrusion width -- suddenly, it's dropping down to 0.16 mm -- the exact value I was testing before.
Something really wonky is going on. It's possible that the 0.16 mm value was present at startup, and is retained in memory somewhere and mistakenly referenced.
I am an idiot lol
It causes the extrusion rate to suddenly drop by ~300 microsteps per second. Yikes!
[Edit: well, I'm an idiot. The wonky thing that was going on was that my spreadsheet was messed up. Some of the formulas -- where the odd values appear, were erased and somehow a fixed value was in its place.
I fixed it and now the extrusion rate is perfectly consistent. lol. Ooops. move along, nothing to see here!]
[Edit again to clarify: my original assertion, that increasing X/Y gcode decimal precision "completely alleviated" the extrusion rate inconsistency, was basically correct. The problem in my spreadsheet came about at approximately the same time that I implemented the increased precision change.
The end result is that my last build does indeed solve the extrusion rate inconsistency, sort of. Infill (and perhaps other non-perimeter path types) have slightly worse consistency than perimeter paths, but it's still accurate enough so that tiny 0.16 mm * 0.04 mm extrusion paths have extrusion amounts that produce extrusion rates consistent to within ~0.01 microsteps per second at 100 mm/s. Without adjusting the precision, the infill can vary by up to ~20 microsteps per second with the same settings. This is because the rounded vector, having a much different length than the precise length, due to having an absolutely tiny length to begin with, is not used to calculate the extrusion rate -- the precise vector is. I'm referring to vector here to mean the literal vector described by two subsequent G1 lines of code. The underlying math is a vector norm on the set of points before they are rounded for Gcode output.
BUT, there is a feature in solid infill to "adjust spacing to fill the space evenly," which in turn adjusts the flow for some segments of solid infill to be slightly different than other areas. I.e., it's not a fluctuation anymore, the infill (solid only?) is sometimes calculated at a slightly different flow rate. I'm experimenting with new builds that disable this feature, but now extra-large gaps are left -- where there is enough space to fit a whole extra line of infill, so I'm not keen on forcing that change in the experimental builds.]
