It doesn't matter, because doing it as a hard-fork is a bad idea. So, if anyone will try to do that, then it will be just yet another altcoin.

I don't know, why developers with that much experience think, that it can be done only as a hard-fork. It is quite easy to notice, that it can be done as a no-fork (not even a soft-fork), because any node, at any time, can always say "I don't have it", when asked about any block or transaction. And then, ZK-proofs can be provided in a different P2P message, for new nodes, which could handle it correctly.

I don't understand, why people do need any "multisig committee" at all. Because if you have ZK-proofs, then you can enable them for all transactions. There is no need to pick, which transaction should went through ZK-proof, and which one shouldn't. If the end goal is to make it easier to process the chain, then everything should be treated with ZK-proofs, because it is better to speedup everything, and not only some portion of the chain, and keep the rest slower, and handled in old, plaintext way.

But they can. It can be a no-fork. For example: some nodes are storing transactions in compressed form. And they didn't fork the chain to get there. If you can compress and decompress any transaction on-the-fly, then you can stay compatible with the protocol.

Also, refusing to provide a transaction or a block in plaintext, is a similar thing, as when you seed a torrent file. If one peer doesn't have it, then another peer will. The only problem is when nobody has it, but in case of payments, it could simply mean, that nobody needs it, and then that single coin can become unspendable in practice (and can be easily made spendable again, if anyone will find that data later).

So, the better approach is to push all transactions through ZK-proofs, no matter if they are payments or not.

It is not. Even when we run out of timestamps in 2106, then it could be also solved with a soft-fork. In that case, old nodes could see for example constantly reorged chain, while new nodes could see it smoothly going forward. But old and new nodes can live in the same network, if needed.

It doesn't, because it is in the coinbase input instead. The meaning of OP_RETURN was different then, because you could spend anything with "OP_TRUE OP_RETURN".

Also, no consensus rule forces you to store the content of the Genesis Block, because it is unspendable. You can just keep its hash, if you want to, or stick to the 80-byte header, if you want to be safe. But the content of transaction 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b can be entirely removed, and you will end up in the same chain, as long as your node wouldn't allow changing the first block from 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f to anything else.

Because the first transaction is unspendable, so it is never stored in the UTXO set in the first place. You need it only to prove, that the chain started in 2009, and not in 1970. But on the protocol level, the Genesis Block is hardcoded, so as long as SHA-256 is strong, you don't need to store it in your node.

It is clearly false, because otherwise, we wouldn't have any soft-forks. Also, in that case, we would have something more similar to BIP-17, instead of BIP-16. And then, instead of introducing any new opcodes, we would always wrap everything in the long chain of old ones.

Why not? For example: signet blocks have 1 MB max witness size, instead of 4 MB. Which means 250 kB legacy space in practice. And that change would be at least consistent with 300 kB blocks, proposed by Luke-Jr. So, if they would shrink blocks, it would be at least consistent. And fortunately, mining smaller blocks is a no-fork, because miners can mine even empty blocks, with only the coinbase transaction, if they want to. So, pools controlled by Luke-Jr, can decide to shrink blocks they produce, and contribute to the smaller total blockchain size.