I can only answer part of this. This might be useful to you, but someone else will need to answer parts I cannot answer.
First, the dev kit module requires the SD card and does not have eMMC. The commercial module uses eMMC, and not an SD card. The flashed images are not necessarily compatible, although they could probably be made compatible with some changes (I could not guarantee this, but I don’t have both models so I could not even test). FYI, the commercial module would work on the dev kit carrier board, but during flash, the name of the target would differ, and the content going to “/boot” would differ.
If you do not have a carrier board for an NX, then you might consider purchasing both a dev kit and a commercial module (which unfortunately would also require a heatsink/fan…the dev kit has this). If you do have a carrier board, then you could skip the dev kit, but during testing it is extremely useful to have a dev kit carrier board for flashing even if you do not actually intend to use that carrier board.
One image for one release will not work with another release (unless it is a minor patch update). For example, do not expect any R28.x image to work on any R32.x release. Do not expect an R32.1 image to work when mixed with R32.4.
Do not expect image originally from the same release on a TX2 versus that release on an NX to function.
That said, the content which differs will be mainly in two places: First, the boot chain content, including non-rootfs partitions and the “/boot” content; Second, various drivers and firmware, e.g., device tree and the GPU driver. The TX2 and NX have different GPUs.
You mentioned command line flash variations, so you obviously are familiar with command line. An additional detail is that the “Linux_for_Tegra/rootfs/” is originally a purely Ubuntu release, and that before flashing this, the “apply_binaries.sh” script is run to add content specific to Jetson hardware. This includes a GPU driver, some libraries, and some firmware. Newer releases add this as a “.deb” package. If you’ve installed your “Linux_for_Tegra/” content via JetPack/SDKM, then this was probably done for you. If you manually unpacked the “driver package” onto your host PC, then you would have also had to have manually unpacked the “sample root filesystem” into “rootfs/”, and then run “sudo ./apply_binaries.sh”, which would have installed this driver content and is when the purely Ubuntu content becomes “Linux for Tegra”.
Regarding apply_binaries.sh, this is a script you can read and examine. In older releases, prior to adding content via the dpkg mechanism, this was just a recursive unpack of files. It would have been simple to just overwrite a different release by running apply_binaries.sh a second time (well, this would leave old drivers and libraries in place if they had a different name, but configuration would have only pointed to the newer files). In newer releases which depend on dpkg you cannot simply install new packages which are in conflict of other packages.
Note that to use dpkg for install this also means apply_binaries.sh began using QEMU and a chroot into the actual “rootfs/” directory. You can examine what commands are done by QEMU to some extent, but you might have better luck running apply_binaries.sh into some scratch “driver package” and “sample root filesystem” location you are not actually using, and logging this (even if you have to use a mouse copy and paste). You could see the actual dpkg commands as they run. You could log this once for the release your TX2 uses, and again for the NX SD card release, and again for the NX eMMC release. Maybe they are the same packages, maybe not. If you are going to edit an image on a TX2 to work on an NX, then this would tell you what packages need to be replaced.
The “optional packages” on a Jetson, such as CUDA, will probably differ between TX2 and NX. The CUDA compiler would be the same, but the target GPU architecture would differ if the content was compiled for a TX2 versus an NX. If you’ve installed content on the TX2 you want to run on the NX, then I’m not sure which packages would need a recompile (possibly the same software other than this GPU target, but in some cases it might be completely different software due to being different GPU architectures).
About the NX booting from SD: Every Jetson has many partitions used in boot. Much of this is equivalent to what PC would consider the BIOS/UEFI (Jetsons don’t have this in hardware, so it requires a custom version of the equivalent depending on module and carrier board). Those partitions must all exist, and typically on either an eMMC model or a model which supports both, that non-rootfs content goes to eMMC. The models which only have an SD card obviously cannot store that content on anywhere except the SD card. The flash command line argument will determines in part where various parts of the start of boot point to for finding this.
When you actually perform the flash command the “rootfs/” content is further updated, but only in boot-related edits. The “apply_binaries.sh” will have added much, but the actual flash will alter some details, such as the “rootfs/boot/extlinux/extlinux.conf” file to adjust for boot target. For example, the “root=” in extlinux.conf will need to name a partition or a UUID, and depending on flash parameters/target, this will change, and thus this final edit. It is then that the “rootfs/” content is used to generate the image to flash.
When you run “flash.sh -r”, it implies you have an image you want already in place as “bootloader/system.img”. This image will be a 100% exact bit-for-bit match and will in no way be altered. This is how people usually use a clone.
There is another method which you might be interested in for your case. Assuming you have a safe protected clone and are not using your original and only clone copy, then you could instead mount the clone on “rootfs/”. If you then “umount” the loopback image, the original “rootfs/” will again become available. For this I assume you leave the loopback mount in place. Since you are not using SDKM to run the operation it implies you are free to run “sudo ./apply_binaries.sh” and have it update the loopback mounted clone instead of the stock “rootfs/”. It also means that the adjustments the command line flash.sh would have installed go to your clone instead.
If you manually run QEMU after examining how “apply_binaries.sh” works, and if you have a log of what is done during “apply_binaries.sh”, then you could perhaps manually update various “.deb” packages and remove packages which conflict. You would have effectively migrated non-compatible “.deb” content to new and compatible content.
Of course there may have been other libraries or content which is incompatible going between a TX2 and NX, but they are the same CPU architecture, and so it isn’t likely that you will find much which is incompatible outside of what was already mentioned.
FYI, you won’t find any “official” support for cloning from a TX2 to an NX. All of the above is to help you do so unofficially. Assuming the two use the same L4T release, I think it is possible, but as I mentioned before, I have not actually tested this.