Leaving the backends up to an abstract system that lets extensions plug-in new types of notification backends would be a good idea.
I'm starting to get interested in the idea of some extension sending out some message over a socket to something that sends out some XMPP or maybe even growl notification.
The current design (as discussed, but not written up) is that individual extensions will be able to define types of notifications and how they are to be handled. And then the user can choose which notifications they wish to receive and so forth.
Each extension will "publish" to the broadcaster, who then Does The Right Thing. Modifying the Broadcaster could possibly do things like spit out XMPP notifications and the like; that's a clever idea that I hadn't thought about.
Given your note on having multiple types of notifications we may actually want to formally include the possibility of any number of notification broadcast types.
Given one type of notification type input it's easy for an extension to simply come up with it's own preferences checkboxes. But given a number of possible notification types and a number of possible ways of being notified we may actually want to build this using some sort of specialized grid of preferences. One where say the horizontal axis is the types of output email, iOS/Android app push, XMPP, and other plugins and the vertical access is the types of notifications you may receive.
Something like that will probably be a huge mess to create unless we formally include the notion of any number of notification source types and any number of possible notification outputs.
