boot2v4
boot2v4 is the version of boot2 found on most Wii's. It was initially released on the RVL-CPU-20 and broke older versions of the HackMii Installer in addition to providing hardware compatibility. It was later bundled in the 4.2 update to overwrite BootMii-boot2.
While boot2 does not check signatures (as it never installs any titles, which is when signatures are checked), unused signature checking code had the signing bug fixed in this update.
Unsoftmoddable Wii rumors
This version of boot2 was initially released because RVL-CPU-20 consoles had simpler power supply, which made them require extra initialization. Because all of the updated IOS versions were distributed with 3.3rev03 and 3.4, people began spreading rumors about boot1c and this boot2 version blocking homebrew[1].
In reality, while the cheaper power system was mostly responsible for the strange behavior of homebrew, boot2v4 was also partially responsible. The HackMii Installer normally reloads into mini to perform low-level operations, then reloads into boot2 with an arbitrary title ID patch. Older versions of mini checked for 4 u32's, 2 of which comprised the title ID. The first u32 was present in boot2v2 and boot2v3, but boot2v4 does not have it, which caused mini to not patch anything, and load an unpatched boot2, which simply loads the System Menu. This was trivially fixed by removing the first u32 from the expected pattern.
Update bug
Besides on boot2v1 units, this is the only time Nintendo ever pushed a boot2 update, and they did not test ES_ImportBoot very well, resulting in many bricks, which Nintendo refused to fix under the assumption that those Wii's had homebrew on them. For this reason, the HackMii Installer has a custom installer to install BootMii.
There seems to be a bug where after ES_ImportBoot checks the hash of the written boot2, it calls ioctl 1 of /dev/boot2 (which seems to flush the write buffer, which is normally empty besides before IOS_Write returns, then write some metadata from the /dev/boot2 FD), then call ioctl 3 of /dev/boot2 (which presumably copied the updated boot2 to the backup copy) regardless of the hashing result. It is not known if this is what caused the bricks in 2009.