Note: I'm a homebrew developer and a strong advocate of public development. I've been burned a number of times. This makes me very biased, so keep that in mind and try to see the actual point I'm making. I only speak for myself.
And are you guys fairly certain that salt's CFW will become the new standard way of hacking?..
I'm fairly certain that (unless they get their act together) SALT's CFW will
not become the standard way of hacking. Based on what's out there right now I can pretty safely say (assuming they release at all) that they'll either make their own little ecosystem (that, due to the shit SALT's given us, homebrew developers will avoid unless it's
really cool) or they'll release a bunch of tools and extensions for the existing setup that will just extend what's already there. Either way, you're better off if you adopt the current CFW situation, avoid coldboothax, and enjoy what's currently out there rather than some nebulous possibility. The days of danger around the public code are well and truly over. Sans' thread is outdated, releases have been made, and the basic stuff is safe, along with pretty much everything else (except coldboothax!) If it's on HBAS, it's safe.
One more question: If the kernel has been hacked, and the IOSU has been hacked, then what is stopping us from creating a hack similar to A9LH where you don't need rednand any more (because on the 3DS you can restore sysNAND even if you brick)?.. Is there some thing in the wii-u that hasn't been hacked yet?..
AL9H takes hold at an insanely early stage of the 3DS's boot process, allowing homebrew code to run even in the event of a brick. However, the best the Wii U has (the incredibly dangerous system.xml coldboothax) occurs just before the system menu appears - all that guff that happens while the Wii U logo is onscreen is outside of our control at this stage. This means that, should you brick, there isn't much we can do about it - the console dies before the exploit gets a chance to run. An exploit that happens much earlier (ideally boot0/boot1 but anything ARM-side would be fine) would fix this issue and allow BootMii-style tomfoolery; making the console basically unbrickable.