I will admit that learning Perl 6 has just found its way onto my TODO list ... somewhere. That is a very interesting language.

Back on topic, is Pluggable a mixin? Would this refactoring change the interface exposed by other classes that use Pluggable? Could the original "narrow" interface have been a goal in itself?

The original version fits on a single screen here if I stretch my edit window, while the refactored version crosses that threshold into requiring scrolling. For that reason alone, I expect that the original would be easier for me to debug, although the exact threshold here is a quirk of my environment and YMMV. I am also assuming, based on the reputation of St. Larry, that the Perl 6 debugger is at least as capable as the Perl 5 debugger when inspecting the function of seemingly monolithic blocks of code.

I do not know enough about Perl 6 to be sure, but the refactored version "feels like" it may do more work than the original. This may just be a cognitive bias because it is longer, and the actual code paths may be more efficient or at least equivalent if the new functionality is not used, but it "feels" questionable to me. I do not know if Perl 6 can inline my sub or not, but I know that calling a sub is not free in Perl 5 (among the best as far as interpreted languages go, but not free) as I learned using HTML::Parser on long and complex documents.

An aside for the interested reader: HTML::Parser for Perl 5 can either call a sub or push an array reference containing the arguments that would have been passed to the sub onto an array, with the latter implemented entirely in XS code. I have seen significant performance improvements by simply storing such a "parse trace" into an array and then processing the array with foreach compared to actually handling the nodes as the parser encounters them. Note that those improvements only come if the entire handling is in the loop body: HTML::Parser is very efficient and sub call overhead is small in Perl 5, but it is not zero!