From the Marlin code, it looks like an M112 command would be as close as possible to implementing this in software. This seems to be what FDM control software that contains software E-Stop buttons (like Simplify3D) use to implement the behavior of the button.
This isn’t as guaranteed or as fast as pulling the plug, but appears to be the best possible way to implement this.
There appear to be approximately two buffers in the path between the PC based control software and actual machine movement. There is a byte data buffer for the actual serial communication, and then there is a command buffer in Marlin that holds parsed and waiting-to-run commands.
The M112 command will get preferentially run whenever it enters the command buffer and does not need to wait until the current command is done executing. However, it will still need to wait until it gets past the data buffer and reaches the command parsing code.
Looking at the github history on the issue, it appears that the Marlin developers were historically nervous about warranting any particular behavior for software e-stop because of the unpredictable nature of buffering, and some users argued that it would be preferable if people wired up the reset switch on boards (e.g. the little button we have on the side of our RAMPS board) to actual big red buttons, since hitting the reset line on the board would have a guaranteed and immediate effect. (https://github.com/MarlinFirmware/Marlin/issues/190)
However, later on (May of last year, https://github.com/MarlinFirmware/Marlin/pull/851), someone submitted a change to implement M112 with its command-buffer-jumping behavior that is “close enough” that host software has started using this, if not for “E-Stop” buttons (which some feel might be promising too much), at least behind the implementation of their “Cancel” buttons.