> Regards the vote; I don't believe that @@ has been proven unworkable,
> however if I'm wrong about that, then the second choice selection from the
> last vote would obviously take precedence.
I don't believe the concern is that we have something unworkable sitting
in front of us right now, after all if that were the case we would not
be needing to have this conversation as the RFC would already have been
What we do have, is a deep sense of unease that we collectively made the
wrong decision, based on, in part, incomplete information.
While the initial block to @@ has been remedied by a larger
language-level change, that the problem existed at all provided a clear
example of the widely unforeseen challenges associated with the @@
syntax and its lack of closing tags, and focused renewed attention on
long-term consequences which where perhaps not given enough
consideration during the vote.
There has been one occurrence already, there will likely be more in the
future. But what specifically will they be and how severe? We likely
will not know until they happen.
But what we can say with reasonable confidence is we have an option on
the table that is technically superior, has an implementation ready to
go, and that will significantly allay the fears of many in internals who
feel that the @@attributes syntax poses an unnecessary risk of burdening
Lets' not commit ourselves to 20+ years of supporting a syntax that we
already have strong reservations about before it's even out the door.