Do you remember the details? First time I hear of something like this.
Re: RCT - I read up on it a while back and the overall impression I got was that it was an application-level re-implementation of NTFS write change journaling. So filed it under 'exotics' and moved on.
Skimmed through the specs again now and I think that it's a good feature to have. Basically, RCT gives the program a change list for a VD for free IF it knows how to retrieve it. I made a note, will see what I can do. Thanks for the nudge.
RCT not only gives the change list, but I believe it also ensures that on a cluster shared volume (CSV) there is an easy way to safely get the changed blocks. Normally a VSS operation on a cluster shared volume puts the drive into redirected mode, in which all IO has to go through the host that owns the CSV at that time. That also negatively affects performance, effectively limiting throughput to whatever the network speed is instead of the usually much faster SAS bus.
Re: full scan issues - that's likely due to bvckup2 being too aggressive with the IO. This is something that's easy to change [1], though I realize it's not a very good excuse and it should not require manual tweaking to begin with.
I didn't end up deploying it because for Hyper-V, performance of the differential scans was really poor, and IIRC there were some issues with cluster shared volumes.
Have you considered adding Windows' resilient change tracking support to bvckup2? I think with RCT and hooking into the API for backup quiescence, you could make this an enterprise grade backup product for SOHO IT needs.