Well, allow me to clarify this a bit:
1 - Event Driven Model - Already exists today. The API is there and nobody is using it like this. You could ultimately combine this with the third model. This is used for 'messages' sent by modules, not specifically email. The email part would notify certain users. The missing thing here from your thoughts is some type of UI for users to choose what they want. In the current setup, this is done by role and I believe you would use this for something like module errors sent to an admin for example.
2 - Search Index Driven Model - This would actually require a third model I am actually talking about. It would also require a seperate 'module' or provider that handle the search processing logic and some type of possible setup/options. This reminds me of some type of site subscription model. I think of something like google where you can get notifications when keywords appear in the news or were recently indexed by its engine.
3 - Email Notification Driven Model - This is simply a queue. It follows a FIFO in the beginning and a scheduled task must be in place to make sure this is being run. There would be no delay other than it waiting for other emails to finish sending that were in place before the current ones just sent. This WILL NOT BE an email marketing type service. All the modules do is pass to a new table a list of who is getting the email, and some settings (html/text, template style for example) along w/ the email subject and body. In the case of the forums, if email notification need to be fired off after a new post, the list is generated in the module along w/ the email subject, body, text/html, template maybe. This gets sent to that table, and the scheduled task will eventually send it.
Once in core, this could be tied to core services as well as profile input items which would lead the way to your other models.