The elegant solution is segwit precisely because it doesn't require a hard fork. There's nothing cool about a hard fork, it's the opposite of elegant. Also you are asking for things that don't make sense technically. Segwit is everything that's needed to fix transaction malleability and so on, and it will make the LN better and allow us to have Schnorr sigs and other cool stuff that anyone that isn't a troll or stupid would agree to add at a protocol level.
Clearly you know nothing about software development. Hard forks are always times more clean and elegant than soft forks. The only problem with hard forks is that nodes which fail to update are going to be left behind for sure. SegWit's soft fork is no better than a hard fork because old nodes won't understand segwit transactions and they will just ignore them. For that reason SegWit is even worse than a proper hard fork.
SegWit won't activate unless there is strong consensus reached. Guess what? An elegant hard fork can also be made in a way that it won't activate unless a strong consensus is reached. Then why we have a soft fork hack called SegWit in the first place? There is no good reason for that. It's just dumb. They propagate this "soft fork" idea as if it was any better than a hard fork just to find more acceptance. It's a clever marketing. Why do the Core devs need sneaky marketing? So many questions, I'd say they are doing foul play. My own writings have now made me realize that I hate SegWit even more than before.
I think segwit introduces more complexity to the system than its fixing and reversal will be too difficult and dangerous to take the chance....
Thankfully there are other scaling offers on the table we can consider, including bu's gradual scaling approach and the new solution from lead devs called "teechan" definitely is worth considering before we do anything hasty like segwit