Quote

If ECDSA and ECSDSA on secp256k1 curve are to become obsolete, they need to be removed completely IMO

I don't know if people will decide to destroy the only 256-bit calculator in Script, that we currently have. And also: it is possible to use OP_CHECKSIG in a way, where it would be safe, if ECDSA will be broken, but if SHA-256 will still stay strong (for example by using it to check Proof of Work in output scripts, so second-layer protocols on top of Bitcoin could be mineable).

Quote

and that requires a hard fork

No, because even if all existing UTXOs will be made unspendable, and the block will be required to have zero coin amounts in the coinbase transaction, and nothing else, then it would still be a soft-fork. More about evil soft-forks: https://petertodd.org/2016/forced-soft-forks#radical-changes

Quote

In such a scenario we no longer need SegWit, it too can be removed.

So, you want to soft-fork-out of Segwit? Interesting. Because if everything will be done only in legacy space, and no additional commitment will be done anywhere (for example in the coinbase transaction), then it will reintroduce malleability, O(n^2) transaction hashing, and other problems, for no reason.

It is technically possible, but I would say unlikely. Rather, I would expect "second witness", where you would have "legacy space", "witness space", and for example "commitment space", created only for new address types. Which means, that we could have "max_block_size = N * ((4 * legacy) + witness) + commitment", and instead of 1 MB legacy, or 4 MB witness limit, we could have "N" MB commitment limit, as a new max block size definition (along with other restrictions, to make new outputs JPEG-resistant).