[Android Q&A, Help & Troubleshooting] Defier525:
I think that it is very essential to actually confirm or falsify this hypothesis first. A friend of mine has a Nexus 4, and when he unlocked the bootloader he simply intercepted the first boot after "fastboot oem unlock" so it went straight to the bootloader again, leading to userdata not being wiped at all.

[MENTION=3021624]launchon[/MENTION] I don't own any of these "probably-secure" devices you mentioned (Nexus 5 or OPO), but if you don't mind, please backup your userdata and internal sdcard and try "fastboot erase userdata" with your locked bootloader. In case this should be successful, boot your ROM and see if you can access data on sdcard or not. In case this erase behavior is broken on all Nexus devices, adding TWRP password protection would only protect you in case your data is encrypted (to some degree).

I can only tell from my personal experience with the Sony Xperia V Stock ROM. I had data encryption turned on and after entering the wrong passphrase too many times, the device rebooted and wiped my data without prior warning (I didn't know that!)! To my big surprise, only userdata was affected and the internal sdcard remained untouched. If you look at the partitioning scheme used on this device (which I mentioned in my last post) you will see that there is no such thing as /data/media, with media being just a symlink or something and with sdcard and userdata being physically on the same partition. Instead, there are two partitions: mmcblk0p14 for userdata and mmcblk0p15 for sdcard.

Also, my Nexus S has two flash memory devices: One mtd device and one eMMC. It seems like userdata, media and system are on eMMC while the rest is on MTD. The eMMC part is also split in separate partitions for userdata, media and system:

~ # ls -l /dev/block/platform/s3c-sdhci.0/by-name
lrwxrwxrwx 1 root root 20 Jan 8 20:26 media -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 20 Jan 8 20:26 system -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 20 Jan 8 20:26 userdata -> /dev/block/mmcblk0p2

Well, maybe my understanding of how Android does mount the sdcard into encrypted data is wrong. Please explain it to me. As far as I have seen, you can specify "encryptable=sdcard" in fstab.vendor (like it is done e.g. for the Nexus S) - see this fstab. My understanding is that Android then encrypts the sdcard as well, putting a second cryptofooter at the end of the internal sdcard's partition and not using one cryptofooter for both userdata and internal sdcard. I will try to find out by experiment and post the results.

I looked into the source for fastboot.c, but I did not really understand it so I cannot tell what fastboot erase really does. But it seems like it falls back to less secure erase in some situations. After erasing, I was unable to retrieve the cryptofooter (which was previously there) and also other parts showed just zeros, therefore I assume that your description regarding DISCARD is correct. Yet, it would be better to dd if with zeros or random data afterwards but for the "regular burglar" scenario you mentioned it should be sufficiently secure.

I certainly will. Nevertheless I am not sure if I understood you correctly: You already tried to fastboot erase your OPO with locked bootloader and it denied to wipe it or you just suspect / expect it to behave this way without having actually trying it?

Why not simple store it in / of /system with appropiate rights? If someone gains enough rights to read that, he should certainly also have enough rights to replace a password protected TWRP with something insecure (or less secure, that's what this thread is about).