[Verizon LG V10] emdroidle:
My theories

Based upon the reports, here is my speculation as to a few pieces and my thinking of how unlocking might be done. First, I'm guessing there were two sets of developers involved in the LG V10 bootloader they had somewhat different goals and assumptions so the characteristics of their pieces are different.

The first set are the developers at Qualcomm. They want their processors to successfully boot if at all possible. Bricks are Bad Things(tm) in their view. They also want their client's part of the boot process to be as painless as possible even though they won't do everything for them. Based on the reports my guess is the boot process for the 808 looks like:

if verify(mmc0.sbl1) then mmc0.sbl1.boot()
[STRIKE]else if verify(mmc0.sbl1bak) then mmc0.sbl1bak.boot()[/STRIKE]
else if verify(mmc1.sbl1) then mmc1.sbl1.boot()
[STRIKE]else if verify(mmc1.sbl1bak) then mmc1.sbl1bak.boot()[/STRIKE]
else boot 9008 mode

Where the mmc0 bus is connected to the on-board eMMC chip and the mmc1 bus is the SD card. My reasoning for this is the 9008 debrick report. Clearly the Qualcomm 808 chip is able to load sbl1 off an SD card.

The second set of developers are at LG. They want the bootloader to reliably load THEIR code. Anyone else's code they don't care about. As such my guess is the boot process for LG's sbl1 code is roughly:

in case of booting from sbl1:
for exec in "pmic", "tz", "sdi", "hyp", "rpm", "aboot":
do if verify(mmc0.exec):
mmc0.exec.execute()
else:
sys.exit(1)
[STRIKE]in case of booting from sbl1bak:
for exec in "pmicbak", "tzbak", "sdibak", "hypbak", "rpmbak", "abootbak":
do if verify(mmc0.exec):
mmc0.exec.execute()
else:
sys.exit(1)[/STRIKE]

Not nearly as reliable as Qualcomm's boot code, simply hanging if something fails to verify and crucially exclusively loading its child programs off the internal flash. Their code would be a lot nicer if in case of one of the pieces failing to verify, it passed control back to the Qualcomm bootloader and let it try its next option, but they don't really want us running our code on the hardware they developed. This would explain why replacing aboot bricks devices, the LG portion of the bootloader hangs in this case.

Given this situation, I would propose a method by which we might be able to unlock with relatively low probability of a hard brick. First, wipe sbl1bak, this disables the backup bootloader. Insert a spare 512MB-8GB micro-SD card into the SD slot and run `dd if=/dev/block/mmcblk0 of=/dev/block/mmcblk1`, you might also save a copy of this data on a desktop computer. I would then replace "pmicbak", "tzbak", "sdibak", "hypbak", "rpmbak", "abootbak", "raw_resourcesbak", and "sbl1bak" with the versions from an H901. I would then wipe sbl1. Next use another spare micro-SD card to save another image of the flash. Finally, I would wipe "sbl1bak" leaving us with a still running, but non-bootable phone, the reasoning is...

NOTE: You need to tell the phone to unmount the SD card before running the `dd` command

The theory is at this point we can control whether the phone boots the VS990 bootloader or the H901 bootloader. Insert the first SD card and the Qualcomm bootloader should load the VS990 sbl1 stage, which will load everything else off the internal flash. Insert the second SD card and the Qualcomm bootloader should load the H901 sbl1bak stage, which loads the other H901 stages off the backup areas of the internal flash.

This actually seems a fairly safe approach, this gives us a backup method available if things don't go the way we hope they do. Yet in spite of this the method is still quite risky. If you've got a phone with a good warranty and a pair of 512MB-8GB micro-SD cards lying around this may be good to try.

EDIT Nov 27: Previously I'd been comparing the information by comparing numbers in two separate windows. Upon using my computer to its full potential turns out something I'd been reporting earlier is incorrect. It appears ALL of the V10 devices I'm looking at have raw_resources and raw_resourcesbak at the same block range, so transplanting a H901 bootloader isn't as difficult as I'd feared. In addition the type and id UUIDs in the GPTs are identical, so upon examination transplanting the bootloader is very likely to be successful. The id UUIDs for other slices^Wpartitions though do though differ from device type to device type (system and userdata id UUIDs differ between the H901 and VS990).

Two important questions remain. Does "Enable OEM unlock" option inside "Developer options" work via the exact same mechanism between the H901 and VS990? Does `fastboot oem unlock` work via exactly the same mechanism for the H901 and VS990? I'll speculate the former is reasonably likely to be true, but I suspect the latter is almost certainly false. This will mean you'll need to keep replacing the bootloader with the H901 one if you try to stick with a semi-stock firmware.

EDIT Dec 1: I'm inclined to tweak the above proposed method. Instead of wiping sbl1bak and then backing up to SD card, I would backup first and mostly follow the process. The big deal is the second image should have an invalid sbl1 (so it doesn't try to chain to the VS990 bootloader in the primary areas), while having the H901 booloader in the backup areas.

EDIT Dec 5: Upon some experimentation it turns out I was wrong about the backup bootloader areas. The V10s will not boot from the backup areas if the primary area is damaged. This leaves me wondering what role the backup areas are supposed to serve. Do they have version markings and the bootloader will copy them over the primary areas if they're marked as being more recent?