Fork #2: Up to a deadline, simulate an advanced zero-cost QC attack by letting any miner who has access to the corresponding public key of the address is authorized to spend it into a null address deducting a fixed fee. After the deadline, we are back to the normal situation.
...
Fork #2: Before the second deadline OP_CHECKSIG always pushes 1 (true) if a special flag is set. This flag is set if the transaction follows a defined format which guarantees that after deducting a predefined amount it is burning its (single) input to a specific (void) address. This behavior is reset to default after the deadline.
Interestingly, unlike what happens with your, rough approach, p2pkh legacy wallets that are not been moved for any reason are expendable for eternity as long as they are privately mined (not being relayed in the public network before being confirmed) in the presence of QC equipped thieves.
What is the point of that? Instead of having two forks, why not just have the one fork have the deadline be farther away so that people have more time to migrate. The point is that during the migration period, ECDLP is still not broken yet.
What is the point of burning the coins? Why would anyone even want to reveal their pubkeys to a miner just to gain nothing? Only the miners benefit from that, it's completely pointless to anyone else. it's the equivalent of just having a fork that completely disallows OP_CHECKSIG.
but we are dealing with a mess, aren't we?
I disagree. It isn't a mess until QCs actually show up. Migration to PQC is pretty straightforward and non-messy, just needs a lot of time and warning.
Noways to minimize the damage unless you get hands dirty, no choice. And yet it is not too much, implementing both forks is easier than what they look like in the first glance
The two forks are just so much more complex than a single fork which disallows OP_CHECKSIG and OP_CHECKMULTISIG after a deadline. And I don't think they're any easier than they seem, consensus and the script interpreter and far more complicated than you think, especially with anything that requires storing state or remembering previously executed scripts.