It seems strange to me that the ordering of finalizing a particular block changes whether block 210 is invalid or valid-headers. I would expect behavior similar to the marked comment (see below) where finding a block forked from before a finalized block would be marked as invalid, same as marking a block as finalized invalidates prior forks.

Since this diff is building upon existing behavior, this should be fixed in a future diff.

marking this line (see related comment)

There is really no point tracking down every single orphan that ever existed since the beginning of time. It only matter that we do so for chain that actually have more work.

assert_equal(node.getbestblockhash(), tip)

Checking that the top block is at a certain height do not test anything useful and certainly do not test what is described in the comment above.

This is not testing anything, really, it just makes the test more fragile. You want to check the best block is tip, regardless of tip's height.

You want to test this is tip's parent, not at height 0209 in general.

Same apply here. getblockhash can help.

Oh yes. You're correct. Sorry for the confusion. "Finalize block should not be alt_node's tip" is more correct that the current message because the message is making an assumption of what the value could be. These kinds of messages age poorly as modifications to the test and underlying code may change the behavior.

The block is never accepted. in fact it is not even downloaded, as we can see by the state "valid-headers". The block is ignored as it is on a minority chain.

You shouldn't need to use this. A wait for is preferable as it would ensure the magic is working by itself without the test having to shovel blocks back and forth.