I think sending to old output types should be made non-standard, but not invalid. Because even now, you can send coins to "OP_TRUE", or to "OP_2 OP_2 OP_ADD OP_4 OP_EQUAL". If every existing output type will be disabled, then it would simply mean, that we will no longer have any Script.

Again: Non-standard? Sure, why not. But I don't think invalidating it is a good idea. Also because new, quantum-resistant addresses may be considered unsafe in the future, may be broken classically, may be used to post JPEGs on-chain, and so on. Later, if people will migrate, and if everyone will be sitting on a quantum boat, then we may consider invalidating things, but I think we should start from non-standardness first.

Again, it is a good reason to never invalidate UTXOs, which were previously valid and spendable. If things will be harder to spend, but still spendable, then recovery could be still possible. Which means, that if someone wants to invalidate UTXOs, then instead, it is better to require additional proof from the very beginning. Which means, that to spend for example old P2PK output, a regular DER signature would be required, as it is today, and also, a new requirement can be added, to put some ZK-proof or something like that in the witness space, in the quantum-commitment space, or wherever it fits.

It could bring us more features, than some people may expect. For example, if it would be possible to go from every existing public key, to every existing private key, then OP_CHECKSIG will become just some 256-bit calculator, with built-in addition and multiplication. And then, many interesting Scripts could be deployed on top of that, for example "<signature> <pubkey> OP_CHECKSIG" as the output Script can be spendable, and then it can be used instead of proposed OP_CHECKTEMPLATEVERIFY.

Not only that. Also, the solution would then be more suited to the particular attack, which would materialize on-chain. When SHA-1 collisions were produced, hardened SHA-1 version was made, to block a particular attack, and not protect us from all possible collisions. Which means, that if some weakness in ECDSA will be published, then that particular weakness will be addressed by some source code, and not all cases, where ECDSA could be broken.

In general, if OP_CHECKSIG will be fully broken, and if revealing any public key will be equivalent to sharing the private key, then still, there will be many scripts, which would still be unspendable, or hard to spend. For example: "OP_SIZE 10 OP_LESSTHAN OP_VERIFY <pubkey> OP_CHECKSIG". Even if public key is equal to the generator, then still, moving such output will probably require breaking SHA-256 as well.

No hard-fork will be needed, if coins will be timelocked, instead of being burned. Also, outputs with zero satoshis can be used, and then, the whole implementation of coin amounts can be changed, while all old nodes will see every transaction moving zero coins in all inputs into zero coins in all outputs.