I think it is important to expand a little further on this "reverse" or "historic" debugging. I think to understand complex systems and behavior in those, to replay "events" which make state explicit is absolutely crucial.
What I want to express is that you are not alone in wondering why this technique is not so much applied today or why the related problems are rarely discussed clearly.
So let’s emphasize two very important concepts here:
1.To understand a programming system it is helpful to make state explicit
2.To even further understand a programming system replaying sequences of state (events) can help a lot.
Here are some sources which tackled the problem and proposed or designed solutions for the problem (dealing with state in complex systems):
-Out of the tar bit, paper: http://shaffner.us/cs/papers/tarpit.pdf
Main ideas: avoid, isolate or make state explicit
This is a combination of two concepts: Command Query Segregation and Event Sourcing. There exists different implementations ( Java,C# , Scala).
The replaying of Tate sequences and the evolving of a domain model are the crucial parts here.
If you really zoom out and see the very broad picture you can already see that with the "rise" of functional programming people are already ((un)consciously ) attracted to fp because it makes state explicit!
But that only deal with point one, to address the second one you need another concept which could be "loosely" described as functional reactive programming.
So you might say all well and good but who actually uses CQRS and FRP? I would say (IMO because I don’t have concrete numbers) actually a lot of companies its just that they don’t know the work they do has this terminology. Maybe you google a bit around and you hear from enterprises which use CQRS, there are some success stories already out there.
FRP too is rising slowly as an example I could give Netflix: http://techblog.netflix.com/2013/02/rxjava-netflix-api.html