Nice. That, plus the first item I mentioned, real-time forwarding, would mean that fails would show up immediately in your sending program, rather than a possible bounce message from a forwarder. Anything that can reject mail should work that way. The recipient's final IMAP server, which may have spam filtering, should also pass back rejections as SMTP statuses. So, if you get the "send completed" from your sending SMTP client, that should mean it's in the recipient's mailbox waiting to be read. This would improve the user experience for person-to-person email.
This is completely backwards compatible, so it's quite do-able as an enhancement. Most email forwarders today are old and from the store-and-forward era, and from systems where opening large numbers of TCP connections was a problem.
There's a sub-status for rejected spam:
550 5.7.1 Delivery not authorized, message refused
That subcode list hasn't been changed since 2003. A few new codes would be useful. I'd suggest:
550 5.7.8 Message refused - spam
550 5.7.9 Message refused - not compliant with laws in recipient's region. (CAN-SPAM, etc.)
550 5.7.10 Message refused - phishing attempt / hostile code
550 5.7.11 Message refused - previous messages from same sender also refused
Let the spam filters talk back that way to the delivery services.
It would be useful if mail delivery services noted such statuses and gave the sender a spam strike.
They don't have to pay attention to that info, but the better ones would.