Anyway the stuff Mike is saying about being able to detect upgrades is
incorrect - detecting an upgrade is *easier* with a soft-fork, just look
at the block header nVersion numbers and warn the user if they increase
beyond what you know is valid. Bitcoin Core implements this IIRC, and
bitcoinj should.

Nobody said hard forks shouldn't have an associated block version number increase - that's a straw man. They should! The difference is only whether older clients are presented with data they would refuse to accept thus ensuring they don't accept the new version blocks.

Meanwhile, what I said is correct. New version numbers result in only a log print. Being hard forked off results in both log prints and the -alertnotify being run: it's noisier, and if the user followed the instructions printed to the console when there is no config file present, he/she should also get an email or some other kind of more meaningful alert.
 
Finally, please stop trying to imply that all this is settled and I'm somehow an idiot for bringing it up. You've done that on the pull request and now here, it gives me a headache. Instead of making hand-waving references to "stuff on IRC ages ago", explain why it's better to keep these nodes in some fantasy world where they think they're fully validating but are actually not.