user47827: This question is similar to this Signet question on Signet nodes enforcing different Taproot rules (old and new) pre mainnet activation. Instead it is regarding how a valid Taproot spend on mainnet according to old Taproot rules (that were never enforced on mainnet) initially treated as anyone-can-spend by the network, doesn't create a massive re-org when new Taproot rules are activated on mainnet.
For example, let's say I created a UTXO encumbered by Taproot rules as they were specified in July 2020 (before the Taproot BIPs were changed from a squaredness tiebreaker for the R point to an evenness tiebreaker). I managed to spend from this UTXO by following the Taproot rules as they were specified in July 2020. Of course Taproot isn't activated at all so all nodes would have treated my transaction as an anyone-can-spend and my transaction would easily have made it into a block. Now let's say in June 2021 Taproot is activated on mainnet with the new rules as they were specified post August 2020 (with the evenness tiebreaker). What is stopping my transaction from failing verification against the new Taproot rules and creating a massive re-org back to the block that contains my transaction?

user5406: 
Of course Taproot isn't activated at all so all nodes would have treated my transaction as an anyone-can-spend and my transaction would easily have made it into a block.

No, the new output types for soft forks are constructed in a manner that they are non-standard for old nodes and thus do not get included in the mempool by old nodes, and therefore also not get mined into blocks unless the miner explicitly overrides default behavior.
If a miner includes such a non-standard transaction before the rules are active, it's not a problem since the transaction is valid according to the old rules—otherwise old nodes wouldn't be able to follow the best chain after the rules got activated. The rules go into effect with the activation height and don't apply retroactively.
If a miner does so after the rules are active, they create an invalid block which gets rejected by all nodes enforcing the rules of the freshly activated softfork.

47827: <p>This question is similar to this Signet <a href="https://bitcoin.stackexchange.com/questions/98642/can-we-experiment-on-signet-with-multiple-proposed-soft-forks-whilst-maintaining">question</a> on Signet nodes enforcing different Taproot rules (old and new) pre mainnet activation. Instead it is regarding how a valid Taproot spend on mainnet according to old Taproot rules (that were never enforced on mainnet) initially treated as anyone-can-spend by the network, doesn't create a massive re-org when new Taproot rules are activated on mainnet.</p>
<p>For example, let's say I created a UTXO encumbered by Taproot rules as they were specified in July 2020 (before the Taproot BIPs were <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-August/018081.html" rel="nofollow noreferrer">changed</a> from a squaredness tiebreaker for the R point to an evenness tiebreaker). I managed to spend from this UTXO by following the Taproot rules as they were specified in July 2020. Of course Taproot isn't activated at all so all nodes would have treated my transaction as an anyone-can-spend and my transaction would easily have made it into a block. Now let's say in June 2021 Taproot is activated on mainnet with the new rules as they were specified post August 2020 (with the evenness tiebreaker). What is stopping my transaction from failing verification against the new Taproot rules and creating a massive re-org back to the block that contains my transaction?</p>
 5406: <blockquote>
<p>Of course Taproot isn't activated at all so all nodes would have treated my transaction as an anyone-can-spend and my transaction would easily have made it into a block.</p>
</blockquote>
<p>No, the new output types for soft forks are constructed in a manner that they are non-standard for old nodes and thus do not get included in the mempool by old nodes, and therefore also not get mined into blocks unless the miner explicitly overrides default behavior.</p>
<p>If a miner includes such a non-standard transaction before the rules are active, it's not a problem since the transaction is valid according to the old rules—otherwise old nodes wouldn't be able to follow the best chain after the rules got activated. The rules go into effect with the activation height and don't apply retroactively.</p>
<p>If a miner does so after the rules are active, they create an invalid block which gets rejected by all nodes enforcing the rules of the freshly activated softfork.</p>
