Assuming that your question excludes any kind of “regular” transmission error (which might also lead to one of the messages not reaching the receiver) the receiver should regard message #236 to be potentially malicious since the “ticket” (what you call “sequence number”) for message #236 can not be verified as genuine.
The specific reaction to such a detection will strongly depend on the individual scenario, protocol goals, and its implementation. In most cases, receiver would (immediately) drop the established communication, regarding message #236 to have potentially been modified by an attacker. If possible, sender and receiver could/should restart the protocol from scratch (including authorization etc.).
Under no circumstances should message #236 be trusted.
The reason is simple: in the described situation, the ticket for message #236 is (let’s just call it) “out of sequence”, which practically breaks the protocol.
Otherwise, there wouldn’t be much reason to use those “tickets” in the first place. The main reason for their existence within certain protocols is to be able to detect (among a few other things) the situation you described, and to react accordingly by not trusting messages that are “out of sequence”.