Rather than putting blocks in a ten minute timeout, would it be effective to treat “reasonable” timestamps with higher priority – so that anytime we see a block with a “reasonable” timestamp, we request its full data and re-announce it, even if it’s only equal-work to our current tip, and if it’s equal-work and reasonable but our current tip had an “unreasonable” timestamp, we switch our tip to the other block, even though we heard about the other block slightly later?
“Reasonable” could mean abs(now() - header.nTime) < 10s && (more_work_than_tip || abs(tiptime - header.nTime) < 10s) where now is our current system time, and tiptime is our system time when we received the header for our current tip, that this new block would potentially replace.