[Nook HD, HD+ Android Development] amaces:
Once all the issues had settled, I was going to ask about power off/reboot to recovery since I made this change. I don't think leaving userdebug had anything to do with it (should be the opposite, since builds are even more locked down now). Alas, I didn't think root/SuperSU would be the major cause of headaches with these builds. About major changes, beyond what I had mentioned last week:

ROW had served us well, but CM12.1 has implemented a very intriguing block I/O priority system, based on BFQ cgroups. Last time I tested BFQ, it wasn't very snappy, but it was a version from a few years back. Once I noticed other devices switching to BFQ to reap the benefits of this QOS-like integration, it was good incentive to add this feature to our kernel. It wasn't particularly pleasant, since we have bits and pieces from the 3.1-3.4 block layer, but it works now.

Now, upstream CM12.1 has been tweaking this integration a lot over the past couple of weeks, and it seems to have stabilized only this weekend. I believe that was the source of audio/video hiccups, not my ringtone priority flag (which is back on now).

The other major change is the toolchain; I've been experimenting with various updated versions of GCC, to squeeze even more out of our hardware. I don't know noticeable the smoothness, and reduced temperature is, but using the latest UBER toolchains (4.9.4 androideabi for ROM, and 5.2.1 eabi for kernel), I definitely notice improvements.

Finally, the transition to user builds (rather than userdebug) didn't happen haphazardly, and there's a purpose to it. On one hand, all the useful features are still there, albeit not exposed automatically, same as on Google Nexus builds. Then, some unneeded features that could potentially steal CPU cycles/memory/slow things down, are deactivated now. In my case, with SuperSU and Xposed already installed, I didn't notice absolutely any drawback, and I abuse my device plenty.

Never had issues with SuperSU, and it's the first thing I install. It sounds like you did everything right, but just in case something more insidious is involved, I'd go back to basics:

Either remove the backup scripts in /system/addon.d, or format /system before reinstalling ROM, to make sure nothing interferes. You shouldn't have to wipe /data or /cache for this.

Afterwards, you have a couple of options: either let TWRP detect the lack of su binary, which it'll install at /system/xbin/su, or manually flash the SuperSU ZIP, which includes the binary plus the user app that allows you to control settings, etc.

When TWRP installs just the small su backend, you are now able to install the user-visible app from the Play Store. With the TWRP approach, the graphical app resides in /data, while the SuperSU ZIP places it in /system. The former approach saves space in /system, and is very useful on Nexus devices, which come packed to gills with GApps (my hammerhead has only a few MBs free in /system).

Once everything works, you should go ahead and install the backup script; SuperSU will prompt you the first time, but I'm sure you found the option in its settings as well.

That's pretty much it. I've updated the TWRP su binary to match the one in the 2.46 ZIP, so you shouldn't even be prompted to update it when SuperSU launches the first time. So, I see no reason for root not to work now. I'm dog-fooding these exact builds, without any root issue, like other folks in the thread. If SuperSU can be used on a stock Nexus ROM, which is more locked down, then it should work here as well.

Read above, and keep in mind that root is composed of two parts: the actual binary and associated scripts, plus the graphical app that you interact with. To reiterate, installing the GUI from the Play Store needs the binary preinstalled in /sytem (e.g., by TWRP) to be actually useful. Otherwise, it's a chicken-or-egg problem.

You should download the official stable version from http://download.chainfire.eu/supersu. When it comes to something as essential as root, I'd be circumspect of download source. Hell, you shouldn't even install ROM/kernel images from random people on the net… i.e., me ;)

Not yet :( I looked at it from different angles since VPN would be useful to me as well, but can't find anything wrong, certainly not on the kernel side. If it's a userspace routing issue, CM12.1 has yet to fix it; plenty of people having the issue, but no solution mentioned.

Sigh… SELinux Enforcing is not the main cause for the power off/reboot to recovery issues, as we established through testing and debugging at least twice already. Even switching SELinux modes countless times, it didn't make any difference on my device, and there are people whose issues disappeared on the current Enforcing builds. It's something about our boot loaders that doesn't get set up properly, and I'm still working on it (see the change mentioned in the first paragraph).