Inspired by discussion on #89.

If the feature set is based on real-world usage by web developers, then some features may need to change identifiers from time to time or accommodate multiple known names. Some possible scenarios:

• A feature is folded into a closely related feature. For instance, subgrid is subsumed by grid. At least one feature is removed and the definition of another feature changes, triggering some sort of versioning event (either at the data or package level).
• A feature has some name but official or popular usage goes in another direction or multiple directions (e.g., es6 and es2015).
• A feature is named erroneously (e.g. felxbox) and we ship with the erroneous name.

Some questions emerge:

• How do we communicate such changes to consumers? (e.g., as release notes, as structured data, or something else)
• How much should we assist consumers in following changes? (e.g., do we maintain a formerly-known-as list for each feature? do we duplicate data access under multiple names?)
• How long should we assist consumers in following changes? (e.g., do we follow a deprecation schedule for outgoing features? do we maintain historic names in perpetuity?)

The answers to some of these questions might influence how we handle versioning (if we understand versions to be a kind of identifier for a feature).

We ought to resolve this issue before a 1.0 release.