Correct me if I'm wrong but the DSU images are essentially an entire image that you can temporarily flash into free space residing on your device. Once booted into you can do as you need troubleshoot or test or whatever the case may be, but as soon as you restart the device will go back to whatever OS is currently installed in this case, GrapheneOS.

If this is in fact true and accurate, what I was hoping to accomplish was to temporarily flash the Stock OS that's shipped with device.
In doing so, one could for example use any or all features that do not currently exist in GOS; Android Auto, Now Playing, Call screening, Google Pay, etc.
Then, once the user has finished whatever it was that they needed to do, reboot the device and now you're back in GrapheneOS.

Is my understanding of DSU Loader correct and would this be possible, theoretically or otherwise??

This is theoretically possible, but maybe not with the GrapheneOS + stock OS combination. These are the main issues I see:

  1. GrapheneOS does not trust any signing keys for DSUs. This can be worked around by leaving the bootloader unlocked or by building GrapheneOS from source and adding the stock OS' keys to the /avb directory in the ramdisk.
  2. DSUs can substitute any partition, but only the ones mounted by Android are actually used, such as system, product, and vendor. Partitions that are loaded by the bootloader are always the GrapheneOS versions. Notably, this includes the boot images (kernel + ramdisk). I don't know if GrapheneOS' kernel is compatible with the stock OS. (If it is, it's necessary to exclude the stock OS' system_dlkm and vendor_dlkm partitions when installing the DSU so that you don't mix the GrapheneOS kernel with the stock OS kernel modules.)
  3. Assuming everything works, it's necessary to disable the OTA updater in the stock OS. DSUs aren't really isolated and have full access to the device. The stock OS is not designed to be installed as a DSU and doesn't take any precautions to make sure it doesn't break things. This is problematic because the OTA updater can potentially overwrite, for example, GrapheneOS' boot image partitions. If that happens and the OEM unlocking checkbox is disabled, then the device will be effectively hard bricked. (No way to unlock the bootloader to fix the damage it caused.)

At some point, I'll probably try this just for the fun of it. It'd probably not be practical for regular use though (and definitely won't work with official GrapheneOS builds).


Google Pay

This will not work, unfortunately. When booting a DSU, the GrapheneOS vbmeta and boot image partitions are still used. Thus, hardware attestation will still report the GrapheneOS public key, not Google's. (Well, technically, it'd report your own key because you'd need to build GrapheneOS from source with modifications to be able to install any DSU.)