And the answer is obvious - don't program it that way. Instead, keep a
sufficient state to allow you to deduce what possibilities could come
up. So, for example, the pass slots can hold entries on the amount of
bus and rail fare paid that day. If I modify your example slightly, and
start with a completely blank card, the sequence would be:

[...snip...]
T/card Rail, Bus, Bus, Bus, Bus, Bus, Bus, Bus, Bus, Bus

The problem here is that there isn't enough information passed to apply the
cap. In the example the first rail journey was zone 1 and 2 costing 2 quid,
but two single journeys in any of zones 2 to 6 would also come to 2 quid.
So a peak 1-2 travelcard might not be valid for the day's journeys.

However I do acknowledge you said "sufficient state" and "for example". A
practical solution would presumably require booleans indicating zones passed
through by rail, both in peak and off-peak, as well as running totals.

The last journey would also need to be read, of course, to allow for the
'continuation of exit' situation mentioned elsewhere recently, and to allow
for things like feeder buses and permitted changes of tram on Tramlink.
Indeed having pondered the Tramlink situation where you are required to
touch in at the tramstop even when changing trams as part of a single
journey (thus at the moment being charged more than a paper ticket), I can't
see anyway they can implement the capping on it unless they consider all
journeys within a 90 minute period as a single journey. In this case
validators will have to read the rest of the journey history anyway to see
if they need to charge. So even with sufficient state the journey history
probably needs to be transferred anyway (at least it does on Tramlink).

Does anyone actually know how it is being done, by the way. I haven't been
clear if other contributors have actually been speaking authoritatively or
just speculating as wildly as I am.