i do understand it. but your diverting away from a block containing transactions where the pool is paying themselves.. to talk about a different scenario about spending later....
because after the 2 weeks of the transactions being (kind of stuck) in a block.. when segwit becomes live for everyone else. the pool can then move the funds using segwit legitimately because they are moving funds from the confirmed blocks using the privkeys they own.
only way to prevent it is to roll back the chain two weeks orphaning off 2016 blocks just to make that malicious block disapear from being confirmed..
as for your newly elaborate scenario about anyone can spend.. those transactions wont be accepted in mempool of old clients. not until segwit is live.
so as i said. a malicious pool can create a block. with a 2 week headstart (2016 blocks) to secure their transaction. and then when live. they can spend the transaction.
Sorry, but I still don't understand your scenario. Can you describe it more specifically with reference to the output type that was used in the outputs?
1. malicious pool makes a segwit transaction to pay themselves lots of coins. from an address they dont own to an address they do own. BUT. because its 2 weeks before anyone else has segwit, it appears to others as a funky transaction. in a block.. so they blindly accept it as a block with funky transaction.
2. so now the receiving addresses is technically classed as having lots of funds.. but no one can spend them as they dont have the keys to do so. so the transaction is locked in the block unspendable becuse although people can try making an anyone can spend, it wont be accepted into other blocks as its not technically an anyone can spend..
3. weeks later when the malicious block has over 2000 confirmations. the owner of the privkey that received the funds can then move them because segwit is now live and segwit pools will see that the transaction is spending funds with 2000 confirmations(even though the tx before that is technically invalid)