Some software will be broken anyway, and then people will have a choice: to upgrade, or to deal with some broken version somehow. For example: timestamps have four bytes allocated. Which means, that after year 2106, we will be forced into hard-forking anyway.
There is one important difference with the year 2038 problem. We know exactly when this problem will appear. Therefore, we have to fix it before then, ideally a few years before 2038. There's no ideal year to hardfork for merging legacy with segwit, and it's not in the same level of necessity. The network won't stop working after year x if we don't merge legacy with segwit.
Cool. I like reading both sides' arguments of this debate.
I agree but I also think in the future we'll get to the point that benefits of a hard fork could outweigh its issues and that can be the incentive to get it done.
I believe it depends on the necessity, but it's very difficult for me to imagine a hardfork introducing significant changes and gaining nearly unanimous support, especially since the roadmap is somewhat oriented to implement changes via softforks.