1) Why does the 'schedule' option in events_handlers only include 'cron' or 'instant'? How about allowing that to be a number in seconds (or 0=instant) for future expansion i.e. in case there is ever any attempt to shuffle load of cron, so that if the system has a lot of things to do in cron it can drop 'later' ones until next time? (Okay maybe this is not so important really...)
2) Where did the 'schedule' option in events_queue come from if the data is only stored once? (Some handlers might have cron, some might be instant.) There didn't seem to be any option to spec this when creating an event. I don't think it should be there (is this an intentional mistake to check I'm reading?)
3) Re events_queue_handlers; is there a number of times after which retry stops happening? Any logic so that retries become less frequent as the count increases? [What I'm really getting at is that it probably shouldn't keep retrying for ever, notifying somebody would be good!]
4) Should there be a way to define 'provided' events as well as 'requested' events? So that we can for example do debug checks that the requested events match up with those provided somewhere on the system.
(edit) AAAAND one more.
5) Event requests should contain a 'filter' parameter, optional, as serialised PHP object. The semantics of the filter would depend on the specific event. For example, imagine there is a role_assign event, but you only care about assign to courses; could be $filter->contextlevel=50. Events that support filters would need to be sent with a callback function that basically returns true or false depending on a $filter.
(edit) AAAAAND another one more
6) Should be a way to define events as 'overwrite' type i.e. an event supercedes other events of the same type/parameters (because it just notifies something has happened, without including any specific data). This allows for potential later performance improvements such as not adding any events to the queue if a previous similar event already caused all handlers to be added.