Here are my thoughts:
As @aluminumwelder pointed out, having the Arduino within the safety monitoring loop is a concern - a firmware malfunction is one of the scenarios that could cause the danger being monitored. Best to keep the safety systems separate from the system being monitored.
This is almost always a mechanical issue with the Ridgid R22002 router adjustment or a configuration issue with a non-standard z motor. There’s a discussion about triggering an alert when the z axis doesn’t move as fast as it should, similar to the alert “The sled is not keeping up with its expected position and has halted…”. More testing is needed to choose a setting value to trigger the alarm (PM me if you’ve got a non-stock Z axis setup and can do some simple tests 
) The “sled is not moving” alert has caused come confusion and is a show-stopper when it crops up, and I would hesitate to introduce another show stopper setting unless it is wanted. Thousands of users have made mountains of wood chips without needing it yet.
The firmware does a very good job of reporting exactly where the sled is, within the limits of the calculations that handle the chains. GC plots the gcode file in one color and the sled’s position in a different color and you can watch as the cut runs to see how they track - or get the “sled…” alarm if they don’t 
. There’s a mimic mode you can compile to play Maslow while you wait for your parts or frame. (Is there any interest in having that mimic mode available as a GC setting instead of needing to re-load the firmware? When in ‘preFlight’ mode, the motors would not run, their positions would be stored while working with the file, then their positions restored when leaving pre-Flight mode). In the mean time:
If a separate monitoring system is interesting, take a look at the " Big Z-value display" in the CommunityGarden - @HansPeterHaastrup did a great job of tapping into the communication between the firmware and GC to make information available in a separate monitoring system. He was interested in the position values that the firmware reports to GC - but the error values get reported as well…