Rick Geneva has a post on the event-based-gateway, offering to demystify it.? Admittedly, this is a feature of BPMN that needs demystifying.? Having worked on the BPM certification for OMG (OCEB), I'm familiar with the event-based gateway.? And I have to say it is one of the uglier creations of an otherwise pretty good notation.
The key source of confusion for users of the event-based gateway is that the events being evaluated by the decision gateway are "drawn" on to the model after the split.? That's not consistent with the way our brains tend to simulate the running of these models with tokens moving along paths.? And it isn't consistent with normal predicate logic where the consequence is described after the condition rather than before the condition.
Having said that, Rick does a good job explaining it.? I'll just add this:? far better (if you can) to design your process to receive a single event that can be interpreted, based on the data it delivers, to cause you to proceed down one path or another.? It is easier to read, just as easy for the BPM engines to process, and it goes back to normal condition-then-action ordering... (and usually yields a simpler diagram).