I guess not.

It does not solve the problem of existing UTXOs. If you have P2PK, P2PKH, and all other types of addresses, listed in tables from this BIP, then you don't see any explanation, how to distinguish between the real owner, moving some P2PK to a new address type, and some cracker, who just produced a valid signature, maybe even without knowing the private key.

Yes, enforcing a proposal, which wouldn't be jpeg resistant, would be hard in practice.

That's another thing worth considering. Currently, we have legacy space, and witness space. Maybe all of that additional traffic should be put into yet another place called "commitment space"? I am not sure, but I saw some discussions about it: https://groups.google.com/g/bitcoindev/c/Lpy4Waz07cg

I think each and every OP_CHECKSIG call should contain an additional commitment. In this way, it will be compatible with existing system, and it will be also aligned with potential attacks. Another incentive to keep OP_CHECKSIG functionality, is to make it double protected: if new, "quantum-safe" address will turn out to be unsafe for any reason, then there will still be a regular OP_CHECKSIG, keeping coins where they currently are, as long as "quantum alarm" is not yet raised.

Also, I think old nodes should not be forced to process new types of commitments, just like legacy nodes are not forced to know about Segwit. Because then, if layers would be clearly separated, it could be possible to soft-fork-out of the faulty quantum-resistant proposal. Some models were broken classically, and I think it is a good idea, to not only have a way to upgrade to post-quantum world, but also to do a downgrade, when needed (for example if a new scheme would allow flooding the chain with a lot of unnecessary, non-consensus data).

Definitely not. When SHA-1 was broken, people introduced "hardened SHA-1" instead, and of course, everyone is encouraged to switch from SHA-1 to at least SHA-256 in next versions, but because of backward compatibility, this process is quite slow, at least in Git.

And here, I guess it would look in a similar way: someone could find some kind of bug (for example SIGHASH_SINGLE), and use it to break something. But: I guess it won't make the system wide open for arbitrary attacks, but rather would allow a particular way of tweaking single things, like it was the case with SHA-1, or SIGHASH_SINGLE. And then, "quantum-resistant" proposals would address just only that, while also encouraging users, to switch to new address types.

Well, we have to pick something, if we want to make any changes. It is easier to take that decision, if you know, how the attack would look like. But if you don't, then it is just a pure guessing. And I think making OP_CHECKSIG more restricted is a better way, also because it was tested in the past (for example when solving malleability issues, by rejecting negative s-values in DER signatures). Here, it would be similar: you would need a regular signature for OP_CHECKSIG, and also some kind of commitment, preferably seen only by new nodes, to not bloat the old ones with features they didn't opt into.

Edit: Another test case for output scripts: "<signature> OP_SWAP OP_CHECKSIG". Here, you can use public key recovery, if a signature is a classical ECDSA, and not Schnorr signature behind TapScript. For a given signature, it is trivial to compute a matching public key, and make a transaction, which will spend that kind of output, as long as your signature is valid. If some proposal claims to solve the quantum problem, and can address this example correctly, then it may be worth considering.

By the way, note that "<signature> OP_SWAP OP_CHECKSIG" is a Script, which means, that it would be a raw Script, or could be put behind some kind of "script hash". This BIP just claims, that "there is hashing, so we are safe". But I disagree, because of cases like that, and some more scripts, which could be also considered unsafe, if OP_CHECKSIG would be broken.

Some people disagree with that: Against Allowing Quantum Recovery of Bitcoin

Yes. For example, in the current secp256k1 implementation, when you have a Schnorr signature, it can take 64 bytes. If quantum-resistant signature would take for example 64 kB (completely broken image resistance), or maybe even 64 MB (completely broken video resistance), then it could be used not only to protect users from quantum computers, but also to store a lot of arbitrary data on-chain. Which means, that the new scheme should not require significantly more resources from node runners.

Also, someone already shared, how different models can affect block sizes:
Well, that way is compatible with scripts. If we would have only "pay-to-quantum-resistant" addresses, spendable with just a single signature, then it would be similar, as if we would have only P2PK, and nothing else. Which means, that if instead of OP_CHECKSIG, there would be OP_CHECK_QUANTUM, then it would be needed to handle more than a single signature, or to combine some signatures in a "OP_CHECKSIGADD"-ish way, and turn N quantum-resistant signatures into a single one, equivalent to executing N heavy, separated signatures in a sequence, and checking if M of N of them are valid. In other words: people would also need multisig in post-quantum world. And they would probably also need scripts.