Here's how our professional organization is using the Events module - We have dinner meetings, the restaurant has multiple selections that a person can order for their meal.  We have them prepay through the Paypal interface.

1. We had to add a separate event for each meal selection, since there isn't a dropdownlist or checkboxlist of items that can be selected.  Note:  in our case, the selection of different options does not change the price or any other elements of the event.
2. We made a report module using SQL to generate a report that provided the paypal status and event information across all these events (we weren't about to look at each of the 4 event items to figure out how many folks actually signed up for what is really a single event).
3. Each subsequent version of an event was only different in its name -- all other items remained the same.  Retyping this stuff was a hassle, so again we set up a SQL statement to copy a prior event -- using SQL is not the most ideal method of handling creating a copy from an existing event.

So, these use cases suggest:
1. adding a table to collect variable information (selections from a checkboxlist, user entered text, selections from a dropdownlist) in the db, adding structure to the module to permit selecting whether a user should have the ability to select options, setup those options, then be able to display the results of those options in a grid)
2. adding the ability to use a prior event as a template for a new event (this would be useful for events that can't use the recurring feature, because each event has slightly different information to be presented).