If the feedrate of a movement command is not specified, it uses the previously used feedrate. This is not necessarily a problem but there is some risk that the CAM software generating the g-code could make different assumptions about the operative feedrates and this can lead to problems.

Personally, I have made mistakes with manually entered g-code lacking feedrates (in start-of-job g-code for a 3D printer for example) which led to undesirable results, although thankfully not catastrophic. Even if the assumed unspecified feedrates are correct for a job, pausing, jogging, and resuming through a GUI can lead to bad results using the jogging feedrate instead of the previous movement within the g-code file.

For these reasons, specifying feedrate on every movement is recommended.

High speeds for Z movements increase the chance of skipping steps. Even worse, the propensity to skip steps is worse when moving up than it is when moving down, which can lead to tools cutting deeper than intended, and in severe cases this can cause fires.

This feature reports the highest feedrate upward and downward. For ramp movements moving Z simultaneous with X or Y, the checker considers only the vertical component of the movement.

In some cases CAM software will generate a large number of very small movements, and in some cases Marlin can perform the physical movements faster than the g-code commands can be sent. This causes the movement queue to be depleted, which leads to slow or stuttering movement of the tool.

On Atmega 2560 based devices communicating over USB the limit has been estimated at approximately 20 commands per second. The maximum rate from SD appears to be much higher, and running from SD is a possible remedy if stuttering is observed.

When a job contains individual movements commands that are long, slow movements, it can make it difficult to pause or cancel a job because the queued commands have to be completed before the UI commands take effect. The LCD readout also shows the status after the last queued command, which may be substantially different from the current tool position.

This feature calculates the maximum duration of the queued commands, assuming a queue depth of 16 movements.

This feature calculates the extreme positions of the tool in X, Y, and Z. Note that this is relative to the location where the machine is homed or to the coordinate set by G92. These zero coordinates must be correct in order for the extreme tool positions to be safe.

For dual-endstop builds, or in general for builds with soft stops enabled, the firmware will prevent movement to negative X or Y coordinates. Attempting to move to negative coordinates will produce movement unplanned by CAM, which will usually ruin the workpiece.

This feature detects if the X or Y coordinates ever go negative. Note this does NOT check the intermediate positions along an arc or spline, which can potentially go negative even if the endpoints are positive.

Some milling machines accept g-code with comments enclosed in parentheses, but Marlin does not. Some CAM software will generate g-code with comments enclosed in parentheses. This can create problems if sent to a Marlin-based CNC machine.

Most g-code jobs operate exclusively in absolute mode. For safety, it is recommended that the beginning of the job explicitly put the machine into absolute mode, or else the tool could quickly run off the end of the machine.

An interface that performs jogging may switch into relative mode and (one would hope) switches back into absolute mode. This feature checks that the g-code places the machine into absolute mode explicitly just to be sure, and warns if any switching into relative mode is present in the job.

Most Marlin/MPCNC jobs are run in mm coordinates, not inches. This feature checks whether the g-code job explicitly puts the machine in mm mode (it should), or if it is ever put into inch mode (it shouldn't).

Some configurations are setup to re-zero the origin at the start, so the position of the tool at the start of the job is effectively the zero point (or a fixed offset from zero) relative to the workpiece.

Less common, but also possible, is for CAM to be performed in absolute coordinates, relative to the machine workspace which is registered by homing (G28).

This reature is purely informative as to whether the g-code job contains a G92 reset of the origin or G28 homing near the beginning.

A tool change command "T0" or "T1" is supported by Marlin for changing extruders, but for CNC tool changes it is unclearwhat it will do. This checks for the presence or absence of any T commands.

Additional information that may be helpful or interesting.