Henrik have a look at EventModel/EventModel because this is were we publish our vm event brain surgery.
yes, that's the idea. but we didn't went further than passing events to HandMorph. At first stage we want to make sure a lower-level event handling (Sensor->World->HandMorph) can be replaced with new model, and then we can enter the morphic and clean it up more seriously. Mmmmhmm, isn't it more accurate to say that events flow Sensor -> HandMorph -> World? (Though, they get pulled in by the consuming world in a polling loop, rather than getting pushed from the flow source)
Anyways, a proper input event modelling is really independent of Morphic, analogous to the WindowClosed/MorphicWindowClosed naming discussion. (which also gives a third alternative to double dispatch/case, in that in use registering to them tend to look like case statements, but loosely coupled)
Cheers, Henry
PS: Looking up an example WindowAnnouncement and ran across it; WTF does Nautilus need special NautilusWindowAnnouncement classes for? As long as your announcer is a Nautilus-specific one rather than the default announcer, that's all the separation that's needed... In other words; favour application-distinct announcers over duplicate Announcement types.
Open a bug entry and send code. I'm sure ben will be happy