[tl;dr:] At this point in time I feel comfortable with continuing to wait and see how quantum hardware development advances before making any decision about whether or not to change bitcoin proof of work (and if so, how) in response to CRQCs.

The first half of this article is not as good as the last half, and it's long -- so if you are going to read only a portion, read the @lightcoin's quantum anti-roadmap. It's pretty darn reasonable.

This is my “anti-roadmap” for PQ bitcoin, projects that I propose should be explicitly out of scope for consensus responses to the quantum threat:

• Disabling spending of QV coins
• Throttling spending of QV coins
• Forced migration to PQ addresses via “zkPKS”
• Non-interactive block-wide PQ signature aggregation

I like the way Light sets some ground rules (which are really the same ground rules Bitcoin has always had) and uses them as guidance for how to evaluate quantum resistance proposals.

For instance, of proposals that eventually disable the spending of quantum vulnerable (QV) coins -- such as BIP 361 (#1471384), Light says:

The problem with all of these concerns, and why, despite understanding them, I am still opposed to disabling the spending of QV coins, is that the same arguments could be made today about any of the number of ways that people are already storing their coins insecurely. For instance, how many hundreds of thousands (millions?) of coins have been stolen from centralized exchange over the years? Yet there are still nearly 2.5 million BTC held on centralized exchanges. Should we disable spending of those coins just because they might get hacked or otherwise expropriated? If another big exchange hack does happen again, should we disable the ability for any other exchange’s coins to be spent just in case?

And as to Satoshi's coins:

Since these “Satoshi coins” haven’t moved in over 15 years, people speculate that the owner is dead and the private keys are irretrievable (without a CRQC). But this is only speculation. We truly don’t know anything about the owner(s), or their intentions for not moving the coins. For all we know, they intentionally left the coins there as a bounty for a CRQC. The point I’m getting at is: not your keys, not your problem. Mind your own coins!

I like this refrain: mind your own coins! Bitcoiners don't need to worry about other people's coins. We say Not your keys, not your coins. We do not say: what other people do with their coins is my problem. Mind your own coins.

we don’t interfere with other people’s spending conditions, and certainly not as a kind of “plunge protection” mechanism.⁵ No amount of throttling of other people’s spending capability is acceptable. Mind your own damn coins!!

From the first half of this article, Light does have this pretty savage description of Taproot address's vulnerability to quantum computers:

Taproot addresses are known to be uniquely QV in a way that every other bitcoin address format (aside from the long-disused P2PK) is not: Taproot embeds a QV public key directly into the address. Using Shor’s algorithm, a CRQC could perform a key reversal attack, brute forcing the private key to this public key and spending the BTC held in the address using the key path, even if the original address creator only ever intended on using the script path. Taproot was designed this way to save 1 byte when spending using the key path, thereby making Taproot the more blockspace-efficient option relative to other address formats and incentivizing Taproot adoption.

And he points out that several soft fork proposals that are not specifically "quantum resistance" proposals could nevertheless be of use:

BIP-347 (OP_CAT in Tapscript) enables the verification of PQ signatures in Script, including Lamport and Winternitz signatures. BIP-441 (the Great Script Restoration, which includes OP_CAT) goes even further, enabling the verification of PQ validity proofs in a standard bitcoin transaction (validity proofs are useful here because they can be used to aggregate PQ signatures). There is also research being done into PQ signature algorithms that can be added to bitcoin in future BIPs, such as FALCON, SHRIMPS, and Guy Fawkes signatures (the latter of which are less signature algorithm, more like a protocol… but still relevant here).