Yeah actually in CheckBlock it sort of 'made sense' because it lacks context, so it at least needed hardcoded flags (though probably it should have been just hardcoded to either SCRIPT_VERIFY_NONE, or better SCRIPT_ENABLE_CHECKDATASIG_SIGOPS as we can get away with that). Here we can be contextual and consult the block script flags.

Either way it's no devastating mistake since this is just a prelim check that misses P2SH sigops, so missing some more sigops isn't hurting.

But, here's a funny one to think about: if we introduce multibyte opcodes, that changes the parsing of scripts, and therefore changes sigops count and would even increase the count for some scripts. There could be some real disasters in such a scenario.

It is a big problem, because someone modifying STANDARD_SCRIPT_VERIFY_FLAGS do not expect to have any impact on the consensus code, and the person reviewing it either.

It's like having a rake somewhere in your garden. You can argue that it's not in the path so nobody will walks on it, so it's not a problem and to some extent you'd be right. But leave it there long enough, and the probability that someone steps on it gets closer and closer to 1.

I am thinking maybe GetNextBlockScriptFlags should accept nullptr and just return SCRIPT_VERIFY_NONE, instead of catching it here.

It seems that is a safe assumption in all cases: pindexPrev is null only when it's the genesis block.

Well in that case, grep for STANDARD_SCRIPT_VERIFY_FLAGS and see there are a couple more rakes waiting to be stepped on ;-P