I'm not sure how exactly this would be implemented, but the general idea is that, when an error is detected in the code, that would stop the robot from running properly, the code would store and check previous versions of the code that works, and would swap out the code.
This would probably require a robot reboot, either automatically or by the operators, but it is still better than having a robot dead mid-match because of a code crash, there could also be manual resets to allow the drivers to revert back to previous working code, in case of a runtime error, that can only be detected by a human (eg, inverted controls, wrong speed scaling, etc).
The system would probably store 3-5 versions of past code, that will undergo automatic and manual checks. For example, if code crashes either during a match or in testing it will automatically be tagged as "Bad" code. Code that was ever manually reverted would also be marked as bad. The user would also be able to version their code, to eliminate all code from previous versions, for example, if there was a physical change to the robot that would prevent all past code to stop working, it would all be tagged as bad so that even code that was technically "working" would not be deployed for a robot that it didn't work for.
Again, like I said I don't really know how this would be implemented, and I'm almost sure that it will be a project on its own, and there are many problems that have to be worked out, like how the code would almost definately need to be stored on the RIO so that there aren't long transfer times putting new code on the robot. And even though, no matter what, replacing the code on the RIO would definately take time, valuable time that the robot is immobile for, a 20-second loss is a lot better than a 2-minute loss if the robot becomes dysfunctional at the beginning of the match