Scenarios that don't pose a concern
Scenario: A valid or invalid Taproot spend makes it into a mined block before activation (block 709632). It is just treated as anyone can spend as no one on the network is enforcing the Taproot rules until block 709632. This has already happened (executed by 0xB10C).
Bad case scenarios (unlikely to occur)
Scenario: A majority of miners (although previously signaling readiness months previous) don't upgrade to a full node version that enforces Taproot rules by the time of activation. An invalid Taproot spend makes it into a mined block post activation and creates a large re-org when it is re-orged out.
Monitor: It may not be clear what full node version mining pools are running. But if they include a valid Taproot spend in a block (with no invalid Taproot spends) that they mine post activation this suggests they are enforcing the Taproot rules correctly.
Scenario: Second layer protocols encounter unforeseen issues due to the Taproot upgrade and need fixing. Laolu Osuntokun recently discussed a Taproot related problem with the Neutrino light client protocol observed on testnet on the bitcoin-dev mailing list.
Monitor: It really depends on the issue re what to monitor but any problems will likely be discussed on the bitcoin-dev and lightning-dev mailing lists.
Worst case scenarios (highly unlikely to occur)
There is a bug found in the Taproot implementation code and we need a hard fork to either fix the bug or reverse the soft fork change.
What bad scenarios have occurred in the past with previous soft fork activations?
Bitcoin Optech goes through the history of soft fork activations here. There have been a number of emergency activations of consensus changes to address bugs though these weren't pre-planned soft forks like Taproot. And of course although the SegWit soft fork eventually activated smoothly in 2017 the months running up to that activation were anything but smooth (You can read about the months preceding the SegWit activation in The Blocksize War by Jonathan Bier). The only pre-planned soft fork activation that encountered problems at activation time was the BIP 66 soft fork in 2015. As Optech states:
The 75% threshold was reached at block height 359,753. On 4 July 2015,
the 95% threshold was reached at block 363,725 and all nodes running
Bitcoin Core version 0.10.0 or later (or a compatible implementation)
began enforcing the new rules. However, at block height 363,731, a
non-upgraded miner produced a block that didn’t contain the correct
block version and so was not valid under the new ISM activation rules.
Other miners built on top of this invalid block, ultimately producing
a chain with six invalid blocks. This meant non-upgraded nodes and
many lightweight clients treated the 96 transactions in the first
invalid block as having six confirmations even though they hadn’t, at
that time, been confirmed even once in a valid block. Eventually
developers were able to contact pool operators and get them to
manually reset their software to return to the valid chain. A second
event of this type occurred the next day, giving transactions three
false confirmations. Happily, all regular transactions from both the
six-block and three-block invalid chains were later confirmed in valid
blocks, meaning that no regular users lost money.
