So where can I download a Q4 2020 version of the program?

After the last update I have found Error 9 creeping into every single attempt of a backup. 

I carried out the CHKDSK /R and all the DISM checks on C:\ and backup disks (all 3 of them) and found absolutely no issues whatsoever. Until it came to cloning ... then came the CRC issue again. So I know I have good disks, I know that the cables (both original and new ones) and all 3 backup disks are OK, I know that I'm doing what has worked for Lord knows how long and yet ... it's still FUBAR. So I tried a full clone not just a Delta. And it still the same utterly fudge and chips Error 9 message popped up.  Frustrated, I looked through previous forum and external discussions on Error 9 yet again and found no joy. I've been in and out of IT since 1984 (Old-Bloke) so I know my way around troubleshooting.

Then I pulled out my size 12 shotgun approach.
I forked out just under $30 for a competitor cloner that doesn't offer Delta cloning. 
It worked perfectly; takes 24 hours or so on a 2Tb drive, but at least it works.
I reloaded Windows 10 on one of the disks: it still worked. (Just checking that last possible platform variable on the OSI 7-layer model.)
and...
I fired up M.Reflect just now and tried to run a Delta clone.  In a confirmed perfect hard/soft/wetware environment.  Identical variables to the dinosaur-slow competitor: from donor disk (where any CRC should force an error) through new cabling, to functional external disk hardware and everything that could feasibly be needed for a perfect backup environment ~ guess what?
>>It still came up with that bl...y Error 9! There is zero chance of a CRC fault. so what the blazes is causing the fault code?  I know that it's not at this end. Everything worked fine until the last update. I haven't had something this frustrating since I was working on Olivetti 8086's back in the mid '80's.
Then I put in one of the dinosaur clones to use as the donor disk.  A completely different disk and, you know where we're going here ~~ The same ruddy fault code comes up on a completely different disk. Same on the next disk that was popped in there too.  Now I'm back on the original platter and Have all but given hope of ever using M.Reflect again.  Only the $30 snail-paced dinosaur seems capable of providing a clone. M.Reflect worked fine just a couple of iterations ago and then bang!

So then, to the sound of maurnful violins and wailing bagpipes, as I said: Where can I download a Q4 2020 version of the program?

Linux & dd if=/dev/sda of=dev/sdb bs=4096 will give you a perfect clone for nothing.. Scroo £30, if you like pouring molasses stored outdoors in January, that's why I bitched about the inability to do the equivalent under Windows with Reflect in the feature requests.

If you're into Linux try "sudo badblocks -svn" (possibly adjusted if you have a 4Kn drive) which is the non-destructive read/write test, costs a couple of write cycles per block, read, invert, write, read invert write back.... if that passes then it's a Windows bug picking up a CRC error where there is none.

I agree that since it starte after an update it is suspicious but stranger things have happened. CRC errors don't have to be hard errors and a slightly different approach to reading may trigger a problem where another method doesn't.
Forget the CHKDSK and similar, download the disk manufacturer's diagnostic and run it for a higher level of confidence. Likely to be a source disk problem on any of the partitions being copied.

Another possibility for CRC errors is a memory problem, the fact it happens with one program & not another might point that way too, since they'll be using different regions of memory in all probability, you might try running memtest overnight just to eliminate the possibility.

Have a look in the Windows Event Logger and see it that narrows down the problem. If the error is coming back through Windows it should record it.
Try Verifying an existing "good" archive. If there is a RAM error it should show up since the verification process is a pretty stringent test on the read integrity of an archive from the disk, into RAM and then the CPU for calculation for numerous block's checksums contained in the file. One bad bit in one block's checksum will trigger a verification error. Of course, the bad part of the RAM has to be in use.
If the Memtest overnight run doesn't help, you can also try replacing RAM sticks with others, even removing the unnecessary ones if you have  lot or if you need them all, just swapping them into different slots.