I just thought of a better way.

Represent the Linux kernel (including out-of-tree-modules) as a profile,
most probably just the system profile (which already exists--extend it).

A user package (for example if referred to by a system service) would
propagate-input the kernel module package it requires.

That would also make sure that conflicts are handled (otherwise they'd be
"handled" by the kernel doing strange stuff at runtime depending on which
package's "foo.ko" got modprobed first if there are multiple files with
the same name "foo.ko" in different packages).

The union to be presented as /run/current-system/kernel/lib/modules would
be all the packages of the system profile which have a
/lib/modules/<kernel-version> directory in their derivations.

It would all automagically work, provided that we modify Guix system so that
whoever populates /run/current-system/kernel/lib/modules does the union.

The limitation of it not be possible for a regular user to add kernel
modules is OK I think.  That's where I draw the line--a normal profile
has no business adding Linux kernel modules to kernel space in the first
place.

Not sure how the interactions with Guix on a foreign distribution would be,
though.  Do those even use the same Guile modules touched here?