Some things I've observes recently working with RSI 3.1. Due to time constraints, I didn't have time to really test these scientifically, so take with a grain of salt.
Despite having my RSI activation in KRL begun with an RSI_CREATE and RSI_ACTIVATE, and explicitly ended with an RSI_OFF, if I ran the KRL program in a loop, the advance run appeared to cause two consecutive runs to overlap. I didn't observe any overlap in the RSI actions themselves, but my RSI-Monitor failed to halt between runs, leading to some very strange looking concatenated data. Adding an explicit WAIT FOR TRUE immediately before my RSI_CREATE appeared to fix things.
I had a small accident with my RSI STOP object. Due to an incorrectly set variable, my STOP object was triggered on the 3rd sample of the RSI activation... and the RSI operation never stopped. I eventually had to stop the robot by hand, but the RSI process ran for nearly 40sec, with the STOP object's input True the whole time. It's pretty obvious the STOP object requires an edge trigger, rather than a state, but I'm still surprised it didn't capture that rising edge at the 3rd sample. It's possible that the edge trigger was so early that the STOP object couldn't see it. Technically, due to the way the bad variable was set, the STOP input should have gone True as soon as the RSI process began, but the RSI-Monitor data showed it False until the third sample. I suspect I may have created a sort of race condition in my RSI container, but I didn't have the chance to research this any further.
Supporting this theory slightly, I've seen other conditions where my STOP object took 4-5 sample cycles, sometimes, to actually halt the RSI process.
...darn it, I had something else, too, but now I can't remember.