Semantics are really important in these situations. We have a system with an E-stop (emergency stop) circuit. Any break in the loop and the system will shut off. It needed to work together with one particular vendors board that insisted on having a "hardware enable" signal that it could control. Rather than adding an additional circuit, someone decided to have "hardware enable" flip a normally open relay in the E-stop circuit. Technically this "works" because enable clears the E-stop condition and allows the thing to function. From a practical point of view this has caused no end of odd problems, particularly when diagnosing issues where things fail because the meaning of this signal has been compromised.
This reminds me of what I've seen happen with the internal health-check endpoint often added to APIs. Simple at first, but eventually there are endpoints to cause the health-check to synthetically fail for deployment purposes; the health-check is also monitoring downstream dependencies; the health-check becomes much more and much less than it was intended to be.
If you're doing three-wire control [0], it also means you can add additional "stop" buttons by wiring them all into the circuit in series.
A nice-to-have addition to your table saw is a big red stop button you can reach with your foot so you don't have to take your hands off of your work pieces to shut the saw down if things have gotten more interesting than you expected them to. Three wire control makes this super easy to add (once you've found the big red mushroom-head n/c switch, of course).
I think for a foot pedal, it'd make more sense to have an enable rather than e-stop. Altough, that also depends on if you only work from one location or many. (Presses in industry often use such a design for hands, so that it ensures you hands aren't in the press.)
