Well, IMHO the question is why is it active in your case ...

cloud-initramfs-copymods has a rather clear, cut use case:
- If booted with an external kernel/initrd make the modules from initrd available in /lib/modules/
- If not, do nothing

That is why "usually" (tm) one has the package installed and it does nothing.
The links that were added all revolve around removing cloud-initramfs-copymods, but IMHO as stated above why was it active when it should not?

Because if booting a "normal" local kernel/initrd it should do nothing.
A random booted server image I had has it installed and no tmpfs mount in /lib/modules just as I'd expect. If I might ask let us try to understand why it is active for Ernst and maybe out of that we find a condition it missed to check to work only in the right cases.

Usually it works like:
0. detect kernel myver=$(uname -r)
0. $rootmnt is usually empty, but if not it would also change where it acts on which isn't the case here

1. if $rootmnt/lib/modules/$myver exists do nothing
1b: only if there is a kernel commandline option copymods=force set it acts without the above

Hence Lucas asked for the content of /proc/cmdline in that other case - @Ernst do you have something set in there?

I wondered how this could happen ..
If one would by accident remove the kernel modules manually and then reboot it would act.
From that moment on any later (re)install of the kernel mods will be in that tmpfs directory, so after a reboot you'd be back to the start.

$ uname -a
Linux j 5.15.0-17-generic #17-Ubuntu SMP Thu Jan 13 16:27:23 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
$ mount | grep /lib/modules
$ sudo rm -rf /lib/modules/*
$ sudo reboot
...
$ mount | grep /lib/modules
copymods on /usr/lib/modules type tmpfs (rw,relatime,inode64)

So this caused the problem, but only due to mis-administrating the system.
And since the initrd does not contain ALL modules that could be in /lib/modules the bug report that "some are missing" as we only get the subset of the initrd.

In this case we are actually happy that we have some modules thanks to cloud-initramfs-copymods :-)

@Ernst:
If you have NOT set by accident or any external source the kernel commandline copymods=force, was there by any chance such an accidential deletion of /lib/modules ?

P.S. If that was what might have happened, the way to resolve is not to "just reinstall the mods" but to remove the tmpfs before that. That isn't easy with the modules open from there.
Most likely you are e.g. disconnecting your network or disk when trying to unload all modules.
Instead use a bind-mount to trick it into the original place "behind" that tmpfs.

# First get all modules (not just the initrd content) into the tmpfs
$ sudo apt install --reinstall linux-modules-5.15.0-17-generic
$ sudo mkdir /mnt/helper
$ sudo mount --bind /usr/lib/ /mnt/helper
# now /mnt/helper/modules/ is the real /usr/lib/modules/ on disk, so copy the tmpfs there
$ sudo cp -a /usr/lib/modules/5.15.0-17-generic /mnt/helper/modules/
$ sudo reboot
...
$ mount | grep /lib/modules
#empty now and we have all the extended modules available

You might need to adapt that to your kernel version, but otherwise - if you got into this by the mistake that came to my mind - it should resolve your issue.

P.S. I see no way to differentiate in cloud-initramfs-copymods between "having no /lib/modules/$ver" and a deletion by an admin. If there is one we could add it to the code to avoid this.