My understanding of the recurrent drive- and drive-letter- related bugs in VBPro is as follows ---
The most important fact is that Windows 9x/Me, XP/2k/2k3/XP x64, and LH/Vista represent three different levels of technology, using three different MBR methods --- 9x/Me and XP/2k/2k3/XP x64 being generally intercompatible, provided older to newer setup order is followed ; LH/Vista not so.
LH/Vista unlike previous post-Win95 OSes implements a radically different pre-boot environment, Unix-like, not DOS-like. However, for retro-compatibility reasons, it continues to be DOS-like- MBR compatible.
Issues appear during Legacy & LH/Vista multi-boot scenarios, basically because unlike previous intergenerational Windows multi-booting, two separate partially incompatible MBR environments are created --- and the lower level is at the LH/Vista pre-boot level, not in the Legacy MBR data --- ie newer is lower than older, unlike all previous cases.
The issue is that the legacy MBR strictly mirrors the boot order mechanically defined in BIOS/CMOS and the physical hardware config, whereas the LH/Vista MBR boot order is defined logically IMO, by the sub-Monad environment needed for Vista pre-boot.
...
Taking the simplest case, XP/Vista dual-boot, there are then effectively several hard-to-reconcile boot levels:
CMOS / hardware config : OT1H defines the physical location of the primary MBR, OT2H simply assures that all drives can be seen by the low-level software and data transmitted to the higher levels
sub-Monad environment: in a XP/Vista dual-boot environment, it is at this command-line level that drive priority is defined --- this is why most (but not all) setups see both XP and Vista (internally and severally) as C: ... (bearing in mind that, except in some Server environments, this is not full Monad --- but the architecture of Longhorn in general requires that this sub-Windows level be managed by some kind of Monad) ... because it appears to be that drive priorities are generated here after OS selection, instead of OS boot choices being generated from the lower-level boot environment, as in the Legacy pre-boot systems.
Vista pre-boot / BCD : here is the source of greatest confusion IMO ... BCD is capable of managing both the Legacy MBR and the Longhorn MBR ; BUT it uses the Longhorn MBR to identify the various boot entities. Boot letters are non-existent at this level BTW
, and furthermore -- unlike in Legacy pre-boot, boot order is defined not mechaniically but logically, by the sub-Monad software environment. However, when booting into Legacy Windows environments, the sub-Monad logically recreates the Legacy boot order, so that the Legacy boot order is recreated, seemingly transparently, but in fact with a potentially incompatible non-Legacy logical structure.
Final level are the dual XP/Vista Windows environments, which is where the drive letters are assigned --- however, unless certain specific pre-installation conditions are created, drive letters assignment will usually be core-variant, and for the purposes of VBPro, occasionally incompatible.
Vista pre-boot order cannot be easily predicted from the hardware config, nor from BIOS/CMOS, nor from the order of drive letters in the Legacy OS, but it is instead an artifact of the sub-Monad pre-boot and sub-BCD environment of the Unix-like Longhorn Core.
Accordingly, I believe that VistaBootPro 3.0 should be developed using Monad ...
...
... it's a long time though since I did any significant coding, and I may have the levels wrong or perhaps even mixed-up here, and especially it may not be Monad specifically but some related protocols that are needed ; however I feel fairly sure that this is a good enough general view of the inherent problems, and that here is the level where the ANNOYING driveswap issues occur and mess up people's dual=boot systems ...
...
Split and moved to own topic by Grav!ty
I'd (just personally) love to see more features and safety nets like that in future builds 
