Recall that the grafting code performs a set of substitutions, replacing
store item names (i.e. file names in /gnu/store) with replacement store
items of the same length, with rules like:
"fx3979c88s9yxdbchyf36qryawgzpwb5-libx11-1.6.10" =>
"rwkqxykm91a75w9afhb41saj0dmf30hw-libx11-1.6.12".
The grafting code currently only checks the first 33 bytes, consisting
of the nix-base32 hash and the "-". It *assumes* that the remainder of
the associated store item name immediately follows, and blindly writes
the replacement string over whatever is there.
In this case, I suspect that within a *.zo file, a Guix store item name
was split into pieces, with the hash and "-" together in one piece but
split somewhere between the "-" and the last byte of the store item.
This results in corruption of the bytes following that piece.
I've recently observed the splitting of store item names in *.zo files
(see <https://bugs.gnu.org/47614>), but in that case the "-" was
separated from the hash, and as a result the reference was _invisible_
to the grafter.