There were two huge discussions on the new
%MY:: interface to the lexical symbol table.

(70 posts) The major thread,
started by Ken Fox, centered around
%MY:: as a language feature to be used and abused.

Is stuff like:

%MY::{'$lexical_var'} = \$other_var;

supposed to be a compile-time or run-time feature?

Modifying the caller's environment:

$lexscope = caller().{MY};

$lexscope{'&die'} = &die_hard;

is especially annoying because it means that I can't
trust lexical variables anymore. The one good thing
about Damian's caller() example is that it appears
in an import() function. That implies compile-time,
but isn't as clear as Larry's Apocalypse.

This feature has significant impact on all parts of
the implementation, so it would be nice if a little
more was known. A basic question: how much performance
is this feature worth?

Most of the discussions addressed adjusting lexical variables during
runtime, and what semantics that would change with what is currently Perl
5's lexical variables. Of particular concern, how runtime adjustment of
lexical variables could defeat the current compile-time optimizations for
variable resolution that Perl 5 currently enjoys, and whether
%MY:: symbol resolution is confined to a physical scope, whereas a lexical
$x may refer to a lexical in an outer scope. These issues are being mulled
over.

(45 posts) Brent Dax also
asked whether
%MY:: should be a real symbol table instead of the current scratchpad structure
currently used by Perl 5. There was a lot of debate on the
differences between lexical and local global variables, and whether that
distinction would help or hinder a transition to a true symbol table.
Much of this decision will be affected by the linguistic questions
discussed above.

(71 posts) Simon Cozens
released an overview of the Parrot interpreter. This is mostly codifying and
coalescing much of the information that has been presented before.
Feedback has been rolled into the docs that will be provided with the
first Parrot release, so you can catch the updated info there.

Later stages of the thread turned into a debate between Paolo Molaro and Dan Sugalski,
centered once again around the decision to do a register-based virtual
machine.