As promised, I'll write some issues related to event modeling, which is my current focus of interest.
The current thinking on event processing and actually on some related areas (such as BRMS), and also reflected in Luckham and Schulte's article on event models is that the first step is to build the data model, and then model the logic on the basis of the data model. According to this methodology there is a need to model the used data and events, sometimes also modeling "business objects" that maybe created from the original data or events. When modelling the logic it always relies on the existing events and data already modeled. This is a "bottom up" approach.
A major issue with this methodology is that it moves the modeling immediately to the IT domain, since business users can relate better to goals, processes, and business logic then to data models. Keeping the modeling in the level of business require to reverse the process, model the business logic first, and leave the data and events as "place holders" which need to be completed later in the process.
A top down modeling is also reflected in that article when the phase of "identify the complex events" precedes the phase of "identify base events". I think that in the business user's terminology it is better to talk about situations that need to be reacted upon then on "complex events" that is more technical (and somewhat ambiguous) term. Of course, modeling is an iterative process, since when getting back to the base events or data, a gap (e.g. event that is not being observed) might be discovered. Thus it seems that the methodology should be: start top-down (goal oriented) and tune up bottom-up.
More on event modeling issues -- later.