This doesn't look like a bug to me; just a case where ideas from the synopses
did not make it into the language. The synopses are not the "spec", they are
just design documents.
I also don't see how your assignment could work, considering how enums ended up
behaving in Perl 6.c. As you can see from the output of the .^mro introspection
method, your enum type inherits from Int, and not the other way around:
➜ perl6 -e 'my Int enum day <Sun Mon Tue Wed Thu Fri Sat>; say day.^mro'
((day) (Int) (Cool) (Any) (Mu))
A variable with a type constraint for a specific type, cannot be assigned a
value of its *parent* type.
Furthermore, it looks to me like the example that you cite from S12, is meant
to be about *native* types - i.e. "int" rather than "Int".
According to the ideas expressed there, an enum with a lowercase name would
automatically be of that native "int" type, as if you had explicitly written:
➜ perl6 -e 'my int enum day <Sun Mon Tue Wed Thu Fri Sat>;'
And then some magic could potentially happen with assignments.
Alas, native-typed enums apparently did not make it into Perl 6.c at all (the
previous example fails with an internal error), and there are no tests related
to them in the official test suite (which is the true "spec"):
https://github.com/perl6/roast/tree/master/S12-enums
In any case, I have a feeling that some of the synopses were written at a time
when native types were thought to be something slightly different than what
they actually ended up being.
For these reasons, I changed the title of this issue to reflect that it is not
a bug, but rather an idea that could potentially be investigated for future
Perl 6.c versions.
