I didn’t downvote, but I think the comment has a factually inaccurate premise: this isn’t a hard fork.
To make future soft forks easier, the Segwit data has a version byte, and unknown future versions are also considered as "anyone can spend". So taproot only had to increment the version from 0 to 1 to work as a soft fork.
But what happens if a miner interprets a Segwit transaction as "pay to anybody" and creates a block that violates the "additional validation" performed by newer miner/node software?
Both will hold value.
And my question is how funds like Grayscale (And 21shares, exchanges, etc) will handle this.
This longest chain is valid for both upgraded and not-upgraded participants. So that's the consensus that everybody follows.
They don't because segwit (or taproot, for that matter) script is flagged using input-space that the old software knows is "from the future" so that it knows it doesn't know how to validate it. As a result, they won't relay it, won't mine it, and won't display it in their wallets until confirmed. But if someone else puts it in a block they'll accept it.
If someone goes and lobotomizes their own software so that it'll mine stuff it knows it doesn't understand, then they could produce an invalid block. But anyone that is upgraded just ignores their block like it never happened.
This is why the activation of such things is normally triggered by a super-majority of hashpower being upgraded: It's for the benefit of parties that haven't upgraded so that even if there are some bad-data-maniacs out there pulling expensive stunts, their invalid blocks are quickly left behind and even non-upgraded nodes won't see many confirmations before the bad block is removed. (And upgraded nodes won't see any at all, of course.)
In the case of taproot 90% of the hashrate has to signal support during any one of several two week signaling periods to trigger activation. If that doesn't happen, people will figure out why and try again (potentially with different activation criteria).
anyone that is upgraded just
ignores their block
Nah, because the post-taproot software will have more hashpower (due to how it activates), the taproot enabled blocks are acceptable to old nodes, and Bitcoin follows the valid chain with the most hashpower.
Bitcoin has introduced changes like this a good dozen times in the past, it doesn't create two separate chains in practice.
The only way it can create two separate chains is if the unupgraded side has a super majority hashpower, one of them modifies their software to mine something invalid under the new 'future' rules... and no humans intervene to prevent that outcome (e.g. by getting hashpower to move). In practice this doesn't happen because the activation is triggered by 90% hashpower indicating that it will enforce. (and won't turn active until November, giving people plenty of time to upgrade)
To old nodes taproot transactions are valid when they've been included in a block, but are invalid when they are relayed on the network.
This is accomplished by taking all the parts of the transaction that are reserved for future extensions and making their use invalid for the purpose of relay, mining selection, or wallet display in advance.
So you can make a transaction that is invalid to new nodes, but valid-in-blocks to old but it'll still be invalid to them for other uses. It's sufficient that new stuff be considered valid in blocks by old nodes for the system to still come to consensus, since only the blocks are included in consensus.
[Thanks for all the questions, BTW, it's been an interesting discussion.]
Taproot is backwards compatible in that non-taproot nodes will just ignore things they don't understand without affecting consensus.
No, after activation of Taproot, coins can be spend in fewer ways than they could before. The new 'taproot outputs' will look like "anyone can spend" transactions to old nodes. It is only new nodes that will enforce the new rules on these transactions.