While I appreciate the sentiment and I do a lot to confirm deliverability of email before I accept it on my personal mailservers (I've made pir.net an entirely virtual domain so mail coming into my backup MX can be confirmed there rather than getting accepted and bounce when getting passed onto the primary, I do a lot of envelope and header verification before accepting email, I don't accept anything that's blatantly spam) if you're doing normal secondary MX you can't confirm deliverability at acceptance time... just that the receipt domain is correct.

A lot of spammers hit the highest MX first, for just this reason and because there will likely be less checking.

In running my own primary and secondary MX I've mostly taken my mail out of the question on this point, but I do backup MX for a few other people. If someone sends email to a typoed address in one of those domains, it gets onto my machine before it's rejected... I still think a bounce message is the correct behaviour. Dropping mail on the floor, silently, without a damn good reason (mine is that it scores over 10 in SpamAssassin) is not a good thing in my opinion even in the current era of joe-jobbing.

Now, sending bounce messages for something detected as spam or a virus, that's not a good idea, but for normal mail I still think it's worthwile.

The problem is the blatant spam. And malware - currently, any approach must recognise that it's trying to sit a small number of good messages from a flood of junk. Dumbly bouncing junk without doing what you're doing and filtering out the obvious spam is irresponsible.

Is it better for me to have an outgoing message delivery failure not diagnosed, or for me to have an outgoing message delivery failure diagnosed, but unknown because it's lost among hundreds of invalid diagnoses?

I would maintain that neither is useful, but the latter case includes a heavy bandwidth, heavy storage, and much time wasted looking through failure messages looking for real messages. When the false positive rate has passed 99%, it's no longer useful.

It's a shame, really. Bounce messages would be useful, if they only came to the sender's attention for emails that I'd sent. That'd require something along the lines of the initial originating mail server remembering message IDs, and ignoring bounces that refer to messages that it never handled.

How much longer can SMTP last, I wonder?

I still do get useful bunce messages and personally (presumably because of my setup) I don't get a lot of joe-job bounces (once in a while but not regularly) so they're not lost in the noise.

Of the last 1000 bounce messages, 1000 were noise, as far as I could see (and if I'm wrong, well, I'm out of luck). But that's one particular joe-job by the PDF spammer, which has now moved on to some other victim, so I'm down to those mail servers that insist on generating multiple delivery failure messages at long intervals.

Neither am I, which is why I don't do it for my domains... but people have asked that I do it for them and it doesn't put an undue load on my systems.