You can do similar things already in C# with several different Microsoft tools: Intellitrace, ETLs, WinDBG/SoS. Though It's hard to do this type of postmortem profiling/investigation unless you have repro steps.
I've not used Intellitrace, but I've heard that it's pretty useful. From what I understand though, it only records things that you've actually seen in the debugger as you stepped through. That does let you step back to any point you've already been. RR lets you record the whole program from start to finish, and then you can debug any point in the recording.
Steps to reproduce are very important; it's no good having any kind of recording if you can't reproduce the bug in one. Once you do catch the bug in a recording, you can replay it as many times as is necessary. One useful strategy has been to record every execution of the program, and only keep those recordings that happened to catch bugs. Another is to record all your automated tests. When a test fails you save the recording for examination.
If Steve had a Linux machine, I could record Aurora every time I ran it then send him the recording once I saw the bug happen. He'd then be able to debug the recording to track down the problem. Second Foundationer seems to have found some very important information. He's found a database where all the ground formations seem to have been saved to the database, but their location information is invalid. That tells us a lot about the error, but it still isn't the smoking gun. If we had a recording of the program as it saved that database, Steve would be able to follow that 0 ID back to where it came from. Maybe the real PopulationID was overwritten, or this copy of the data wasn't completely initialized. Either way, the recording would perfectly preserve that information for Steve to discover.