A couple of points:
1) if you run the simulation with the same seed many times, it looks to me like you'll get the same answer each time. That's the purpose of the seed, to allow replicating a run exactly, particularly for debugging.
2) Laura's suggestion of logging your needed data in memory and reading it at the end has merit, but you might not have enough memory available, and the classic problem with adding this kind of code to your program is that it changes the timing of the program. Since you're looking for potentially subtle behaviors here, it might be better to add as little debugging code as you can.
However, reading the PDF that comes with the simulator, it looks like there's a built in debugger that could be used to do what you need (though a bit laboriously, perhaps). If you have your NANORGs call to a particular location every so often (however often you want to sample... perhaps using a counter), you can run the debugger and use the "s xxxx" command, specifying the address of that special spot. This looks like it runs silently until that instruction is hit, at which point you can dump the org's memory, etc, and use "s xxxx" again to get the next sample. If you combined this with Laura's idea, you could have it run to this "breakpoint" whenever your log memory is full.
That would be a manual process, but if you're quite clever, it's possible you could write a console application that automates this process by running the simulator in quiet mode and feeding commands and reading back responses to/from the debugger.
Another option would be to run the simulator in *its* logging mode, and write a small program to parse the (huge) log file (or find a way to search for what you need in an editor and do it by hand), selecting only those bits of data relevant to your app (perhaps combine this with the trick above so you have a memory location you can search for so you can more easily find the data you need).
Failing all that, let us know and one of us can post to the experts forum and see if we can track down the author of this simulator... maybe they will know more. It's really a shame they didn't include a "emit a debug output" macro of some kind in their assembly language... that would have made this a lot easier.