The idea was that we would eventually promote it.  Along with that promotion, we would do a migration of the events or allow for 3rd party developers to provide "converter" logic from their grabbag events into our now first-class event type.

I'm believing that things will end up on a spectrum from 1 to 2:

1. Nobody really cares about the extended/`grabbag` types.  This case is easy, because everything we do to support it will never be used and thus it will be completely bug-free and without any problems.
2. We get a really lively explosion of developers in our eco-system and all of them go off and define their own, often competing/redundant, types.

My thinking is that if we see 5 developers all trying to create the "same" type, each of them will create it slightly differently.  Some of the decisions they make will be good and others will be less good, depending on how they intend to use the data.  When this happens, it should be our job to look across all of the formats, figure out the commonalities in the use cases and propose a new "first-class" type that meets the needs.

It should be possible to convert the old types to the new type, which could be done by code we write or we ask each of them to come up with a bit of code that meaningfully converts their format.

The trade-off spectrum we have to navigate is allowing for innovation while also pushing standardization.  I think a `grabbag` style, completely separate event will optimize our ability to enforce standardization without hindering innovation, while I fear a truly hierarchical model where anyone can extend our first-class types into whatever they want, will make the efforts of standardization less tractable because it muddies the distinction between standard and customized.

I agree on the overlapping of extra fields, I'm hoping that conventions and communication in the community can alleviate issues that arise from that.