I think there are two use cases for emunand:
#1 - keep sysnand on a low FW version (for future exploits), have emunand at latest (for playing newest games)
#2 - keep all things that make a NAND "dirty", like CFW/NSPs in an emunand, to keep sysnand clean for online play
I think SX OS' solution works fine for #1.
You won't be able to use it online, as sysnand is on an old FW, and emunand is dirty (having all the NSPs, as well as all SX OS CFW logs/traces, and also being 15 GB smaller). But you can have a low FW version, and play games on the latest FW version, without burning fuses and having autoRCM.
For #2... I think it's not really safe, but I don't think it's detectable YET, for now.
The EMUNAND0 magic at the end of BOOT1, as well as the nand00.bin and nand01.bin files stored in the USER partition, are easily detectable. It MIGHT be safe at this moment (as Nintendo should not have had any code to detect these back when 6.0.0 was released), and I THINK they can't add that detection without releasing a new FW version, but I still think it's really dirty how it leaves traces in the sysnand, like that signature in BOOT1 or those files.
Whereas if it were implemented like: having an emunand kip/sys-module, plus having the emunand files in the SD card, then it should leave no traces in the sysnand (unless directly intended by the user), like running Lakka or running a payload in RCM (like Hekate).