All clients do not do this. Why would they? What action would they take? Try and simulate a hard fork in some complicated roundabout manner? Why not just do the real thing and keep things simple?

 

They are already non-standard. That change was made last time I brought up the problems with soft forks. It brought soft forks that use OP_NOPs a bit closer to the ideal of a hard fork, but didn't go all the way. I pointed that out above in my reply to Peter's mail.

So to answer your question, no, it wouldn't satisfy my concerns. My logic is this:

Hard forks - simple, well understood, SPV friendly, old full nodes do not calculate incorrect ledgers whilst telling their users (via UI, RPC) that they are fully synced. Emphasis on simple: simple is good.

Soft forks - to get the benefits of a hard fork back requires lots of extra code, silently makes IsStandard() effectively a part of the consensus rules when in the past it hasn't been, SPV unfriendly. Benefits? As far as I can tell, there are none.

If someone could elucidate what the benefits actually are, that would be a good next step. So far everyone who tried to answer this question gave a circular answer of the form "soft forks are good because they are soft forks".