The new pattern grammar stuff is cool. But, if Perl automatically builds the parse tree with no further work necessary by the programmer, won't that be slow? Perl can't detect that named captures (based on the subrule name) won't be used after the match succeeds, so it can't leave them out. We had all the flack about using $& and use English; when it wasn't needed, so even that one copying of the input string was an issue. Won't this stuff be orders of magnitude worse?

Once the compiler realizes that named captures aren't used, it won't
capture them.

But that means the compiler needs to be able to solve the
halting problem. Which is, for Turing Machines, unsolvable.
And since Turing Machines provide a more powerful machine
than any physical computer does (due to their finite memory),
not even the perl6 compiler will be able to solve this.

Remember that it's only in the general case that you can't
solve the halting problem. Many specific cases are easy to
solve, and things can be designed to make it easier to solve
those cases. In this particular case you'll note that,
unlike Perl 5's dynamic scoping of the current successful match, Perl 6 makes $0 lexically scoped. That makes it pretty easy to tell how you've used $0 and its progeny within a particular block. Furthermore, the opaque $0 object is really not much more complicated than Perl 5's hidden match object. For most of the match, you've got to keep track of your state somewhere anyway. Perl 6 will undoubtedly do the same trick as Perl 5, and produce $1, $2,
etc. lazily from the information.

Named captures are really no different in that respect. The name is really representing an offset into a capture table, and no hash is ever really built, except to hold the symbol at compile time. Perl 6 also will likely escape the $& problem by
using copy-on-write semantics generally.