Well, before we go much further. You could handle this on the application layer. You could be as specific as you want, all we really want to get is the data stored in a meaningful way.
I want to cancel event #2 of my previous example
Event_ID, DateTime(Start), OccurrenceInterval, ...
1, '2012-02-13 00:00:00', 'P1D', ...
Event_ID, Meeting_ID, Length, Notes
1, 1, '3600', 'Just am example of what'
1, 2, '3600', 'Canceled'
1, 3, '3600', 'when you render it'
1, 4, '3600', 'in chronological order'
1, 5, '3600', 'you might want to make'
1, 6, '3600', 'the pkey Event_ID, StartTime'
1, 7, '3600', 'because the pkey should never change'
Inflated version (a view)
Meeting_ID, Event_ID, StartTime, Length, Notes
1, 1, '2012-02-13 00:00:00', '3600', 'Just am example of what'
2, 1, '2012-02-14 00:00:00', '3600', 'Canceled'
3, 1, '2012-02-15 00:00:00', '3600', 'when you render it'
4, 1, '2012-02-16 00:00:00', '3600', 'in chronological order'
5, 1, '2012-02-17 00:00:00', '3600', 'you might want to make'
6, 1, '2012-02-18 00:00:00', '3600', 'the pkey Event_ID, StartTime'
7, 1, '2012-02-19 00:00:00', '3600', 'because the pkey should never change'
The obvious downside being metadata used in the decision of a generated primary key's outcome. I'm not sure what the cascade delete looks like for a view, or even if it's supported. It was just an idea. I think there is something missing here which could be fixed by UUID().
Looking back at it, that's a terrible design. I think you should handle this all on the application layer and just wrap it in a transaction and then just say 1->n (Event -> Meeting).
Edit: I think it's possible to capture the view in a meaningful way. That was the only reason I really proposed this approach. The schema above is certainly not something I would use myself. It's just an idea/rough draft. You seem to have a good head on your shoulders and could fill in some of the blanks I left out like # of occurrences in the Event table and that 'cancelled' would be a flag.