Ok, quite a bit to try to unpack in that last post, and I doubt I'll be able to help you with all of it, but I'll do what I can.
Please do try the Rescue Media method. If that works, then it won't directly answer what's going on in your Windows environment, but it will mean that something there is interfering with Reflect. Many AV applications don't allow themselves to be completely disabled, fyi. Even when you turn them off, in many cases they will continue doing things. Symantec/Norton seems to come up a lot in cases of AV interfering with legitimate activity, both in terms of Reflect and in general. I've seen cases where its scanning tripped Image Guardian because it tried to open backup files for write access (no good reason for that), and they've been in the news recently for, among other things, causing Chrome to crash after Google tried to enable some additional security features within Chrome (twice) and even preventing Windows updates from being installed after Microsoft switched to signing those updates using a more secure digital signature algorithm. This type of nonsense and the fact that Windows Defender now holds up quite well against competitors in independent tests (and is free, unlike many solutions including Norton) is why I dumped third-party AV long ago. They just seem to cause more problems than they solve these days, especially in this era of new major Windows 10 releases arriving every 6 months. Even Macrium has a KB article warning about them here
Image Guardian won't come into play during a clone operation. Its function is to prevent non-Macrium applications from modifying Macrium backup files, such as MRIMG and MRBAK files. It does absolutely nothing to block clone operations or even disk formatting operations, because it operates at a file level. Clone operations and formatting operations are disk/partition-level.
There's no such thing as a "Disk Volume ID". Disk IDs and Volume IDs are separate entities. The fact that you're formatting the destination is also irrelevant because the VSS snapshot isn't of the destination volume
; the snapshot is of the source
volume. The whole point of a snapshot is to give Reflect a consistent "data set" on the source to clone from, while still allowing you to use the system. Any changes you make to the source drive during the clone operation would NOT be carried over to the destination because they wouldn't be in the snapshot, but the snapshot has to be used when cloning from a "live" partition because trying to clone from a source partition that's constantly changing doesn't work. VSS is not trying to access the destination volume because there's no need to snapshot a volume that you're overwriting.
However, a VSS problem would certainly prevent the clone operation from proceeding. The reason the Volume ID keeps changing has nothing to do with you reformatting your destination. It's probably because the error message you're seeing is showing the ID of the VSS snapshot itself, not the actual source or destination volume, and each clone operation involves creating a new (temporary) snapshot with its own ID.
You don't need to make any changes to a freshly formatted drive to allow VSS to work. If you did, then nobody would be able to use Reflect or pretty much any other image backup/clone utility without manually customizing their drives, and even built-in Windows tools like System Restore wouldn't work out of the box, but that's not how it works. And that's why I suspect interference from some other application. (And again, VSS isn't touching your destination disk anyway, so it would not be the culprit here.)
If you have to physically disconnect and reconnect the disk's USB cable after a clone failure before you can try again, then it sounds like a problem with either the disk or your enclosure/adapter. For what it's worth, I once had a SATA to USB adapter that crashed under heavy write activity. I could keep up heavy READ loads for as long as I wanted, i.e. copying dozens of gigabytes of data from the attached disk, but if I tried to perform sustained WRITE activity -- such as cloning onto the disk connected to that adapter -- the adapter would work for a while and then suddenly crash, and then I had to disconnect and reconnect that adapter to reset it. Needless to say, that adapter quickly ended up in the trash. Maybe that's what's happening in your case. If you see this same behavior even in Rescue, then I would swap the USB adapter/enclosure.