this contains the same args as the /etc/default/grub and /boot/grub2/grub.cfg file
this contains the same args as the /etc/default/grub and /boot/grub2/grub.cfg file
rpm-ostree install, where you need to run rpm-ostree kargs manually.nvidia image, you likewise have the nvidia modules bundled instead of layered, and you don't get the same luxury there and need to manually run the kargs command....exe you found requires some undocumented arguments.kargs or cmdline anywhere.set-kargs:
rpm-ostree kargs \
--append=rd.driver.blacklist=nouveau \
--append=modprobe.blacklist=nouveau \
--append=nvidia-drm.modeset=1
just set-kargs command which runs the command I mentioned, it's a manual thing you do after install.
rpm-ostree kargs to add boot arguments./etc/default/grub via the RPM setup scripts in the NVIDIA driver. Yet they STILL tell people to manually run rpm-ostree kargs.rpm-ostree kargs command lists the same kernel arguments. So I suspect they are just using this as a method to update the cfg file that is symlinked to /boot/loader/grub.cfg/etc/ to prevent confusing merges with user-edits vs operating system edits. Anything you edit in /etc/ becomes seen by the REAL ostree as "user edited". I guess they wanted to avoid that./etc/ files from layered RPMs in /usr/etc/ and then systemd attempts to merge them into /etc/ automatically, if possible. This is possible if the file is new or if the edit is trivial. But I am guessing kernel args are non-trivial and won't auto-merge, hence the need for manually editing the grub config.rpm-ostree kargs is most likely just a tool for quickly editing the etc file./etc/kernel/cmdline https://fedoramagazine.org/manual-action-required-to-update-fedora-silverblue-kinoite-and-iot-version-36//etc/ related which explains why some things can't be automatically merged without intervention. But your system as it is now has already had those args applied and should be permanently ready now. 
/usr/etc/ are the "ground truth templates", you can always run an ostree config diff to see what files you have changes in or files that you;'ve kept that don't exist upstream. It doesn’t attempt to understand the contents of files – if you have modified a config file in any way, that wins
/usr/etc/ and the new deployment's /usr/etc/ and then apply those patches to your /etc/ and just ignore the ones that failed to apply.