I don't really want to keep exchanging walls of text here, and at this point from your most recent post it's not even clear what your current state is and therefore what you're trying to achieve in the near term (if anything), as opposed to what things you just sharing about your experience and what things you want to know about Reflect. So once again I'll provide some information where I can, but I don't want to keep this up, at least not to this degree. It takes quite a bit of time to write posts like my previous one and the one below, and also to read yours.
If you have BitLocker support enabled when you build Rescue Media, you can use it on any PC, but auto-unlock will only work for the volumes that were unlocked when you created Rescue Media on the specific PC where you created it, because obviously Reflect won't have auto-unlock files for BitLocker volumes on other PCs that it's never seen before. In that case, you'd have to use manage-bde to unlock the volumes by supplying the password or Recovery Key. I do this even on my own PC because I decided I don't want my Rescue Media to store an auto-unlock key at all. I'd prefer that it didn't store sensitive info, and I'm fine with the extra effort that this entails.
You don't have to install a PE environment for Rescue Media Builder to use it. It just downloads the necessary content from Microsoft and caches it so that it can use those files as the "foundation" for Rescue Media. Or if you download the zip file using the Reflect download agent and have it sitting in the same folder as the Reflect installer when you run the latter, then Reflect will import it during the installation. Otherwise Rescue Media Builder will prompt you to download it the first time you try to build using one of those base WIMs. But starting with Reflect 7.2 there's an option to use WinRE instead, which relies on pulling the necessary files from your Windows Recovery partition. That saves you having to download a larger WinPE environment, and it has some other perks (e.g. it's the only way to build Rescue Media that has WiFi support), but it also has its drawbacks in my opinion. For example, using WinRE means that you'll always build Rescue Media from the same Windows kernel as your main OS, since Windows updates the Recovery partition whenever you install a feature release -- but that in turn means that if there's a bug in that new release, that might break your Rescue Media. And even within a given kernel release, WinRE gets customized per-system even before Rescue Media Builder touches it. For example, my system's WinRE environment is bloated by several hundred MB by my Synaptics touchpad drivers that include some high-resolution video animations to demonstrate gestures -- and that type of per-system customization can introduce problems too because you're no longer feeding Reflect a consistent, known foundation. That's why I personally use WinPE 10 as my Base WIM, which as of this writing means Reflect will download WinPE 10 1709 from Microsoft. That does NOT get customized per-system, and it's a release that Macrium tested. I don't need WiFi support on my Rescue Media and don't mind having to download and cache that WinPE 10 1709 file set.
I too keep my data on a separate D drive, although I chose not to redirect the actual Windows user profile folders over there for various reasons. I just mostly ignore those profile folders and have my own setup on D. That way Windows has no formal dependencies of any kind on my D drive for user profile loading or anything else. Since it sounds like you DID redirect the profile folders over to D, then if D was still locked at the time Windows started, that may well have been why you had profile issues.
As for RDR, if you feel that it's a weak point, I would recommend working with Macrium Support, but given the number of things going on with your system and the number of variables involved, I think it would be very premature to jump to that conclusion. That seems especially true since it doesn't even sound like you ever tested a non
-RDR restore to see whether the end result of that restore was any different, which would seem to be the first and obvious test to perform if you suspect RDR, before you go casting aspersions on it. But I will say that RDR has existed since Reflect V6 arrived a few years back and has been enabled by default. I don't think Macrium would have done the latter if they weren't confident in it, and even if they had been wrong, that choice of having it enabled by default should have resulted in lots of reports of bad restores from Macrium customers since then, and that hasn't been the case. The reason you haven't seen anything in documentation about RDR leaving malicious files intact is because it doesn't
do that. The end result on the restore destination after an RDR-enabled restore is the same as if you had performed as a conventional restore. The only difference is in the means used in order to get there and the time saved.
As for warning that the restore would run without BitLocker, Reflect does normally warn you if you're about to perform a restore that will result in the removal of BitLocker -- you can see that warning here
-- although the fact that you were restoring your Windows partition might have been the wrinkle here. That warning occurs when Reflect is about to restore a BitLockered partition onto an unencrypted or locked partition, as opposed to an unlocked partition. The problem in this scenario was that when you "staged" the restore in Windows, your C partition was unlocked. But apparently it was no longer unlocked in the WinPE environment you had to restart into. Again, that might be fixable by rebuilding your Rescue Media (and therefore the cached file set that the boot menu recovery option uses) with the auto-unlock option enabled. Or frankly I would consider just booting from external Rescue Media whenever you want to restore your Windows partition. You have to reboot into a Rescue environment to perform the restore anyway, so I've never really seen the benefit of "staging" the restore within Windows personally. Just stage it in the environment you'll be using for the actual restore anyway.
I don't know of any specific documentation for performing a system recovery restore, but that's because as I already said, when you're restoring a disk that contains an OS, typically you want to restore the entire disk with the possible exception of partitions that you are excluding for a very clear reason, NOT just restore the C partition and exclude all other partitions even if you're not sure what they are. I agree that if you have a data-only partition that's not something you'd want to roll back every time you want to roll back your OS, and I myself have rolled back my OS while leaving my data partition intact -- but when I do that, I exclude ONLY that data partition from the restore.
I already touched on where WinRE gets its files from. If the system has a Windows Recovery partition exists, it pulls from there. If not, it pulls from a Recovery.wim file that would typically still exist in that situation, since that file gets moved from the C partition over to the Recovery partition during Windows installation if a suitable partition was created during installation, which Windows Setup will do automatically if you're installing onto an empty disk -- but some manual installation routines might choose not to create a WinRE partition. If you want all the gory details on where the WinRE and WinPE files are stored, there's a handy diagram here
. But basically, the WinPE files, i.e. the ones downloaded directly from Microsoft prior to modification, are cached in Reflect's ProgramData folder on C. As far as I know, that can't be customized, but those files can be and are redownloaded if ever required. Then Reflect maintains a separate cache of actual Rescue Media files, including the fully built Rescue Media environment as well as any drivers that it needs to bake into those builds. All of that is by default under C:\boot\macrium. THAT location CAN be moved elsewhere if desired, and that too will be rebuilt automatically if ever required.
Removing the boot menu option just removes the entry from the Windows BCD. It does not blow away the Rescue Media file set cache because that's used even if you want to create a Rescue Media flash drive, disc, or ISO file. However, the boot menu option works by setting up a BCD entry that tells the system to boot from the actual files in the cached Rescue Media file set, so if you delete that cache, then you'll break the boot menu option even if you still have that in your boot menu. But again, Reflect recreates or updates that as needed when you choose to generate Rescue Media.
I'm not sure why booting from your USB drive was "no small task". Typically PCs have a key you can press during initial startup to access a one-time boot menu that will allow you to choose to boot from USB that one time, rather than having to muck around with the general boot order in the BIOS. You might want to find out what that key is for your system if you didn't know that. As for manage-bde not being available, it sounds like your Rescue Media wasn't built with the "Add BitLocker Support" option enabled. Not sure what to tell you about your touchpad or what "Microsoft-generated BitLocker recovery file" you were looking at.