Yep, we use this capability on our ISOs (the kernel and initrd live inside a GPT disk image inside a SquashFS image inside the ISO).
tl;dr: I don’t believe such kernel arguments exist right now. More details:
Here’s the initrd script that we use to boot from an image file, optionally wrapped in a squashfs, from a device passed on the kernel command line with endless.image.device=..., which is parsed here. It’s the same mechanism we use to boot from an image file stored on a Windows filesystem. This does not support an additional layer of loopback-mounting, which you’d need if the ISO is itself stored on another filesystem. (Perhaps there’s something that runs earlier in the initramfs which can loopback mount a file – I’m not sure. Not as far as I know.) endless.image.device and endless.image.file are added to the kernel arguments in our GRUB config.
This is a bit non-standard because for NTFS and exFAT image host partitions we do not loopback-mount the file, we directly map its on-disk extents. Some more info on the how and why in this blog post if you’re interested.
The path to the kernel and initrd, as well as the path to the OSTree to boot, contain an ostree deployment ID which is different for every new release:
These are determined at boot time by invoking the BLS module I linked to earlier. For a given release (3.1.8, say) these parameters are the same for all ISOs, but by design they will be different for 3.2.0 and every subsequent release.
From 3.2.1 (probably) I expect we’ll support an intermediate squashfs on exFAT and NTFS, not just ISO-9660, and it might be pretty easy to add support for (VFAT or EXT) → squashfs → disk image, which would allow you to unpack the ISO to your USB stick and then write the appropriate GRUB config. Supporting (VFAT or EXT) → ISO → squashfs → disk image is likely to be more work unless I’m missing something.