-@item Great Unicode support, with strings represented at grapheme level
+@item Unusually strong Unicode support enabled by strings represented at
+grapheme level and an embedded copy of the Unicode Character Database

IIUC, this means that previously, it didn't include a copy, and now it does? If so, that's bundling, which is to be avoided in Guix such that there is only a single copy to keep up-to-date. From (guix)Submitting Patches:

  8. Make sure the package does not use bundled copies of software
     already available as separate packages.

     Sometimes, packages include copies of the source code of their
     dependencies as a convenience for users.  However, as a
     distribution, we want to make sure that such packages end up using
     the copy we already have in the distribution, if there is one.
     This improves resource usage (the dependency is built and stored
     only once), and allows the distribution to make transverse changes
     such as applying security updates for a given software package in a
     single place and have them affect the whole system—something that
     bundled copies prevent.

(If this was already the case in the previous version, that's still bad, but then it can be left for later, being independent of this patch.)

I noticed you removed the mention of the garbage collector, is this intentional? Seems a useful feature to me ...

On nqp-configure: Are you sure that 'bin' should be installed in '.../bin'? Looking at the Git repository, make.nqp does not have a shebang and can hence not be directly run, maybe you should add a shebang?

Also, is there appear to be some tests in 't', why aren't they run?  There is a 'rakudo-build-system', maybe this rakudo-build-system can properly build this package (including tests, maybe it even adds a shebang for the make.nqp)?

On nqp: why the switch from downloading the source code from the apparent official site "rakudo.perl6.org" to GitHub?

+             (substitute* "t/09-moar/01-profilers.t"
+               (("ok.*\\$htmlpath" html-test-text)
+                (string-append "todo \"harness5 fails to write html profile\";"
+                               html-test-text)))))
What's the issue here? Is it a limitation of the Guix packaging, or could it perhaps be an upstream bug? If the latter, upstream needs to be informed such that they can fix the bug.

On the new package description: everything in Guix is free software, the "open source" is superfluous. The information on who designed it is interesting from a historical perspective, but I don't think it is useful information for package descriptions.  It's getting close to marketing phrases (see (guix)Synopses and Descriptions) with "prioritizes expressiveness", "optimised for fun" and "superpowers", "linguistically inspired" (I mean, doesn't every new language try to gain those properties, and how would you objectively-ish verify those compared to other languages (ignoring C and assembly and such), and what does "linguistically inspired" even mean?).  The other things can stay I suppose.

I've noticed the environment variable changed (PERL6LIB -> RAKULIB), but (guix build rakudo-build-system) hasn't changed PERL6LIB to RAKULIB.  Can you verify that our various perl6-... libraries still build, and that when doing, say, "guix shell rakudo perl6-json-name -- whatever-rakudos-binary-name-is", you can still use perl6-json-name in whatever is rakudo's name for a REPL?

You add some patches, but they need to be registered in gnu/local.mk as well, please do so.
On the patch file name: it looks a little suspect, perhaps if you run the linter on the packages it will have a comment about the file names.

On commit messages: they don't follow our conventions.  Running "git log" will result in plenty of examples, also see <https://www.gnu.org/prep/standards/html_node/Change-Logs.html>. (They tend to be a bit terse, but you can always add additional information to them even when not strictly required.)

A new copyright line can also be added.