In this feature, there are two changes (that we know of so far) that
might cause such observable effects.
1. Not erasing the type parameter of Enum when computing the super
type of a raw enum type.
2. Changing the translation of enum constants. Right now, if you
have an enum constant that has a body, it gets translated as an inner
class, Foo$1. We would probably change that to a named nested class,
such as Foo$A.
In the compiler meeting today, we realized there was another approach
for (2), which was, rather than changing the declaration of the enum
constant from Foo$1 to Foo$A, to instead use condy at the use site (go
through something like ConstantBootstraps::enumConstant) to come up with
the cast target for the cases where a client needs access to a member of
an enum constant that is not inherited from a supertype (which isn't the
common case.) This would allow us to leave the translation of the
declaration of enums alone, and instead perturb the use site, when the
new behavior is needed. Which removes one of our risk items.
