Hello Guix!

I think that I now have some understanding for how these differently 
grafted packages can arise: The grafting code in `bag-grafts' uses 
`fold-bag-dependencies' to collect all the replacements that could 
affect a package.  That function visits all packages in the dependency 
tree depth first and exactly once.  Consider the following example tree:

A → C, B

B → D, C

Package A references packages C and B while package B references D and 
C, in that order.  If both C and D have replacements, then the grafting 
order for package B depends on whether we are considering it on its own 
or as a dependency of package A.  See also the attached dummy packages.

I think that the correct solution to this problem is to sort the grafts 
somewhere before ungexp'ing them in `graft-derivation/shallow'.  While 
package inputs should be sorted by name, they are split into `inputs', 
`native-inputs' and `propagated-inputs', build systems can add packages 
and G-expressions inputs are sorted by lexical appearance.

However the issue with guile-cairo and guile-rsvg seems to be a bit 
different. `fold-bag-dependencies' only considers packages and changes 
to rust-ring turn its source into a package, causing 
`fold-bag-dependencies' to inspect the dependencies.  Specifically, on 
aarch64-linux `fold-bag-dependencies' the following packages and outputs 
are visited near the end:
--8<---------------cut here---------------start------------->8---
rust-ring@0.17.8.tar.gz:out        gnu/packages/crates-crypto.scm:4207
clang@13.0.1:out                   gnu/packages/llvm.scm:241
gcc@11.4.0:lib                     gnu/packages/gcc.scm:743
isl@0.24:out                       gnu/packages/gcc.scm:1404
libstdc++-headers@11.4.0:out       gnu/packages/gcc.scm:1068
libstdc++@11.4.0:out               gnu/packages/gcc.scm:965
mpc@1.3.1:out                      gnu/packages/multiprecision.scm:139
elfutils@0.187:out                 gnu/packages/elf.scm:54
clang-runtime@13.0.1:out           gnu/packages/llvm.scm:145
go@1.21.5:out                      gnu/packages/golang.scm:822
go@1.17.13:out                     gnu/packages/golang.scm:486
go@1.4-bootstrap-20171003:out      gnu/packages/golang.scm:117
gcc@11.4.0:lib                     gnu/packages/commencement.scm:3227
gawk@5.3.0:out                     guix/build-system/gnu.scm:151
make@4.4.1:out                     gnu/packages/commencement.scm:3460
pkg-config@0.29.2:out              gnu/packages/commencement.scm:3453

; note this visit to glibc!
glibc@2.39:out                     gnu/packages/commencement.scm:3103
glibc@2.39:static                  gnu/packages/commencement.scm:3103

binutils-gold@2.41:out             gnu/packages/base.scm:778
bc@1.07.1:out                      gnu/packages/algebra.scm:668
ed@1.20.1:out                      gnu/packages/text-editors.scm:123
lzip@1.23:out                      gnu/packages/compression.scm:703
--8<---------------cut here---------------end--------------->8---

Notice the visit of glibc.  It is also visited earlier but not 
recognized as duplicate by `fold-bag-dependencies', even though it maps 
to the same derivation (This is `glibc-final', there also is a version 
of glibc created by `package-with-bootstrap-guile' earlier).  expat is 
visited before without any change.  The packages with replacements are 
cons'ed so that glibc ends up in front of expat in the grafting order. 
guile-cairo doesn't depend on rust-ring and it just so happens that 
glibc is visited before expat and they and up in the opposite order.

I don't know where these different versions of glibc come from, but 
sorting grafts should also get rid of any problems they might pose.

So why doesn't the bug appear on x86_64-linux?  Here the change only 
causes the visits of `fold-bag-dependencies' up to gawk, in particular 
the visit to glibc doesn't happen and for both guile-cairo and 
guile-rsvg expat ends up in front of glibc in the grafting order.  This 
should be related to the full-source bootstrap.

vicvbcun