> For what it's worth, I looked at the function documentation for Listen and figured I had enough to get going.

I'm not at all sure what you mean here.  Do you really mean the documentation for Listener.Listen()?

> We can't solve the problem of users ignoring docs, but we can minimize the need for "You must do this; you can't do that" through API design.

100% with you here.

> I agree we shouldn't drop during event dispatch (and probably that events in-band with notifications are a bad idea), but the failure mode is really ugly. Especially since there are LISTEN/NOTIFY use cases where you don't care about missing messages (e..g, caching).

We could make the failure mode significantly more obvious by making the event channel unbuffered.  It could delay reconnecting in some scenarios, but probably not enough to be a problem in practice.  Also since the first thing Listener does is send an event when it connects, if you test your program at all, you'll notice that it won't receive any notifications.  Then, hopefully, you'll look at the docs to wonder what's up.

I also like the separate channel for events, since if you're okay with losing notifications, ignoring events is as simple as  `go func() { for _ = range l.Event {} }()`.