FWIW, I note my own trigger for revisiting Perl 6, is the existence of a standards-compliant transliterating implementation of another language, say Javascript,

FWIW, I note my own trigger for revisiting Perl 6, is the existence of a standards-compliant transliterating implementation of another language, say Javascript, written in Perl 6. No ambiguity, just "does it pass the validation suite?", and "how fast is it?". A decade of "it's usable now!" has left that sentence with little signal weight for me. The idea is, at least as of a decade ago, it was straightforward to massage the then ECMA spec into Perl 6 code. The spec says "Go to step 4 ... 4. ..."? Well, "goto Step_4;... Step_4: ..." is code. And so on. Perl 6, at least as envisioned then, is a very nice language for language implementation. Implementation often goes like this: most of the language is easy, nicely compatible with the target; some of it is hard, requiring some struggle to impedance match; and tiny bit of it is impossible, or nearly so, or requires rewriting all the rest, because of "gotcha" conflicts with the target semantics. With a rich kitchen-sink target, almost everything becomes easier, and there's likely some hook you can use to get that impossible bit done. And when writing a compiler, (then, almost) general grammars, and multiple dispatch with type sets, is a nice place to be. But the corollary is, when I don't see a compliant ES2017 transliterated to Perl 6, then I assume something is wrong - something isn't working yet - be it unfortunate spec, or "doesn't quite work yet at scale" implementation, or community.