If Ripple Inc. stopped (for whatever reason) validating RCL for 1 hour and if (that's a BIG if, since it is not a recommended setting for UNLs right now) consensus moved forward regardless, would you re-join the network at the then current stage or when you left it one hour ago? If it forked, would that influence your decision and if you decided to choose a fork, how would you choose?
Currently, we would accept whichever valid ledger (that is, all transactions follow the correct rules) had the highest weight by rippled's current algorithm. That would mean it would have to pass these tests (oversimplified a tiny bit):
1) It would have to have as a prior ledger whatever the last fully validated ledger was.
2) Each step from that last fully validated ledger to the candidate ledger would have to be replayable. That is, the transactions couldn't violate any gross rules.
Of those valid ledgers, we would accept the one with the highest weight. Factors that influence the weight include trusted validations for that ledger and nodes observed to be running that ledger.
So, effectively, we would take the "majority" ledger of those that don't violate sanity rules.
This code is also the code that helps the network recover from a very rare, but always theoretically possible, potential failure mode. There's a trivial proof that consensus will always have some risk of failing. Typically, only a small percentage of nodes fail each round and the split nodes rejoin the pack quickly and cause no harm. It's like a school of fish where 2% of the fish leave every few seconds and the 2% that split off a while ago rejoin. There's always more than 90% of the fish in the school.
But it is theoretically possible for consensus to fragment very badly. You can reduce the probability of this happening, but the cost is reducing the best case speed, so it's better to tolerate it than to avoid it. Imagine this happens and the network splits into ten groups each with 10% of the network and each in their own consensus round. This is effectively the same situation as the one you are hypothesizing, just over a smaller period of time. You need some avalanche of ledgers to get the network back to being able to fully validate a ledger.
Interestingly, this doesn't hurt the transaction rate. Ledgers still close at the same speed. But it does hurt confirmation latency, since you could go several ledgers without any ledger fully validating.