"I'm a mechanical engineer, not a programmer" #10

Yet you manage to write some of the cleanest, best-annotated Python code I've ever read. Bravo!

I love the type hints and the lack of external dependencies.

A couple of small suggestions which are more style/approach opinions than anything else:

• In the main loop, you might consider making the main processing function which expects iter(lines_of_gcode) and returns (or better yet yields) lines as an iterator. Move the file i/o to another function which takes the input file, iterates the lines into the processor, and writes out. The thinking here is to make it easier to eventually integrate into a slicer/gcode pipeline
• I see that there are some comments for syntax using F-strings - IMHO stick with .format for this script and target py3.5-3.7 for compatibility
• Personally, I would parse and validate a line of gcode/comment in a single spot, rather than e.g. #L265 checking if "E" in the string in multiple places. Here's an example regex for parsing gcode. There are python gcode parsers out there, but I like the lack of deps, pip can be daunting for the general audience. No need to get crazy with classes, just a namedtuple or class with slots to contain the values of the fields, or None if not present. Or a dict where keys are letter codes.
• I'd give process_gcode() some sane default parameters
• Add an examples folder with known input/output pairs so contributors can validate their output

Again, excellent work!