Hi Raymond!

Thanks for the attention you've given this and for the words of encouragement. I'll try to make something like this for PyPI.

I do feel I should critique your metaphor of Queues as email.
(Please don't take this as a request to re-evaluate anything about this proposal or re-hash the "farewell messages are an inferior solution" from python-ideas. It's really only about that "basis for mental model" in general, which I think is doing you a disservice.)

Email is principally bidirectional; with Python's Queues, only one side has the freedom to send any kind of coordination instructions via the same transport that's used for workload messages.

Email is principally one-to-one. The *-to-many Queue case is specifically the one where propagation of farewell messages to all recipients is error-prone, with recipients suddenly needing to worry about the existence of other recipients.

(And if you feel that's not valid because you view multi-recipient as part of the core idea of email, consider that such email is basically "broadcast", with every message reaching every recipient - even further removed from the idea of Queues than single-recipient email is.)

The email metaphor tends to imply FIFO consumption, while Queues support other orderings. These other orderings further complicate the code for dealing with farewell messages.

With email, participants generally have handles on each other, and treat the transport as very abstract. With Queues it's exactly the opposite: they have a handle on the transport mechanism and abstract away the other participants; the transport explicitly takes over some burden of coordination and dispatch; and thanks to that it's very easy for participants to enter or leave an ongoing "conversation" without having to introduce themselves to the others.

(I'm realizing now that email is a pretty good metaphor for Erlang's IPC model though.)