The MatchRecoveryAlgorithm can be used by both the Base recovery function (7.4.3) and the Individual recovery function (7.5). The frerSeqRcvyIndividualRecovery defines which one applies. Behavior of MatchRecoveryAlgorithm differs and current text does not reflect those differences.
Issue1: "Each packet accepted and passed up the stack resets the timer variable RemainingTicks (7.4.3.2.4)." This sentence is not valid for Individual recovery, as in that case dropped packets also reset the timer.
Issue2: "The timer mechanism prevents the MatchRecoveryAlgorithm from getting stuck forever, blocking packet 1, in case a Talker fails or is reset soon after initialization." This is not a valid statement. MatchRecoveryAlgorithm cannot stuck as any packet with a different sequence_number than the previous one is accepted.
Issue3: "If a Talker or a relay system fails in such a way as to repeatedly transmit packets with the same sequence_number subparameter (perhaps repeating exactly the same packet), those packets will continue to be discarded, at least until the sequence_number wraps around." This sentence is not correct. If Talker fails as described, then all packets are discarded (and wraps around of sequence_number does not matter). If a relay system fails as described, then the result depends on whether or not individual recovery is used. In case of individual recovery, all packets are discarded (and wraps around of sequence_number does not matter). In case of NOT individual recovery, if there is a correct member stream, then the failed member stream pollutes the correct member stream, no discard by MatchRecoveryAlgorithm. Therefore, I would say that in case of MatchRecoveryAlgorithm it is highly recommended to use it together with individual recovery.
Issue4: Text refers to C.10 also containing incorrect statements.
"The Sequence recovery functions (7.4.2) in the two systems receiving the Member Streams 1 and 2 will discard the repeated packets until the sequence_number subparameter on the good Member Stream 2 wraps around after 65 536 packets. Then, whichever packet 5 is received first will be relayed to the next stage. It could be the new, good, Member Stream 2's packet 5 or the old, bad, Member Stream 1's packet 5."
Statement on packet 5 is wrong. What happens with packet 5 depends on which Sequence recovery function (7.4.2) is used on the member streams. In case of VectorRecoveryAlgorithm (7.4.3.4), the bad packet 5 is always forwarded (as it arrives before and accepted by the history window). In case of MatchRecoveryAlgorithm (7.4.3.5), the failed stream pollutes the correct stream (see issue3).