What is the point of that?
Keeping bitcoin promise as far as it is possible and pushing to the limits, it is the point.
Disabling OP_CHECKSIG means destroying wallets that do not follow our orders, It wasn't part of the code, the contract bitcoin has "signed" with the user. You can't just show up with a new address scheme ordering people to migrate. They have a right not to follow, it is constitutional.
What is the point of burning the coins?
As of 2018 June 4, 19% of p2pkh addresses (4,204,148 of 22,275,753) holding 25% bitcoins (4,319,806 of 17,072,361) were revealing their public keys because of address-reuse.
Such addresses are in the most vulnerable state just like their p2pk counterparts and are indistinguishable from more secure p2pkh addresses with unexposed public keys. They should be blocked too but we want safer p2pkh addresses to be kept valid, burning such addresses by miners through an incentive mechanism is what I've recommended.
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.
It can be a service with a very low fee, centralized and based on trust. The owners of abandoned, expired p2pkh give both their public and private keys to a trusted solo-miner/pool to include it directly in the blocks. lease note that mining is permissionless in bitcoin and there is always a possibility for paranoid minted owners of very fat wallets to lease power and mine their transactions privately.
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.
Forcing people to move their funds and threatening to announce those funds void otherwise? Believe me it is a mess.
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.
Disagree.
Storing state in a single thread of execution of a single script is required and it is nothing more than playing around with one or two booleans and I've explicitly described the rules. This is not dark magic.