This is all fair and good, but my question points to the fact that this *again* reinvents the wheel. Take bounce management for example:
What you describe for bounce management is already in acs-mail-lite, unless you *demand* that you use the email address instead of the user_id (which I find more convenient). It would be something like bounce-<user_id>-<optional unique tag>-<optional additional information>@somedomain.com.
Though this is only a minor change (email vs. user_id) it would yet again change the behaviour of the acs-mail package.
Talking about bounces, how would you handle bounces due to "out of office" replies ?
Furthermore, do you plan to add multipart email handling to the mail package, how about alternative emails, do you want to include internationlization using quoted printables (or other methods) and last but not least what about attachements? Will you create a unique message identifier with each sent mail ?
You talk about queues in your outgoing document. Does this mean you think also about having multiple SMTP servers (which is what I'd understand under a queue for mail sending). Otherwise I do not really understand the need for special queues, as this could be handled by an addition to the notification package where you would see, which packages have what scheduled notifications, what has been send through the notification package lately and (if done correctly) how many messages bounced for a certain mailing. This would enable us to use the same mechanisms you describe not only for mail but also for SMS, IM and whatever other methods of notification we happen to create in the future.
I think the whole queue description (as per your document) belongs to notifications, not to the system for incoming and outgoing mail. Though, obviously the outgoing mail system needs to have an interface with notifications to deliver the information about sent mails and such.
