Systems like gdb process-record-and-replay rely on logging machine state with every instruction [0]. This imposes limitations; for example gdb's record-and-replay system is not implemented on all platforms where gdb runs. Record-and-replay systems can also be impractical for many systems; for example VMWare record-and-replay debugging technically works on Firefox, but it's a tool of last resort because of the performance penalty. The browser can take several minutes just to start up in the record-and-replay debugger. [1]
Because of this, Mozilla developed its own record-and-replay system that is lower-overhead, but that again does CPU-specific and platform-specific work that needs to reimplemented for every OS and architecture, and relies on CPU features that aren't available at all on some processors and add some limitations of their own (like no recording of multiple threads with shared memory). [2]
In contrast, the Elm debugger apparently takes advantage of the language's pure FRP design to record and replay only input streams, rather than low-level machine/program state - a very different approach, with its own limitations, but also very different possibilities like interactively rewriting history by running different code on the same input stream.
I should note that Mozilla's "rr" is actually similar conceptually to the Elm debugger, since it records an input stream rather than a snapshot of the program's states or actions. But the mechanism is quite different, since C++ doesn't naturally isolate nondetermistic "inputs" in the way Elm does.
The title would suggest to someone not already well-versed that this is a unique feature of Elm's debugger, certainly not that one of the most common and popular debuggers does this. It's hype
Because of this, Mozilla developed its own record-and-replay system that is lower-overhead, but that again does CPU-specific and platform-specific work that needs to reimplemented for every OS and architecture, and relies on CPU features that aren't available at all on some processors and add some limitations of their own (like no recording of multiple threads with shared memory). [2]
In contrast, the Elm debugger apparently takes advantage of the language's pure FRP design to record and replay only input streams, rather than low-level machine/program state - a very different approach, with its own limitations, but also very different possibilities like interactively rewriting history by running different code on the same input stream.
[0] https://sourceware.org/gdb/wiki/ProcessRecord
[1] http://blog.pearce.org.nz/2009/03/setting-up-vmware-to-recor...
[2] http://rr-project.org/