So I got this message from a recent imaging:

Consolidation: Merging 'sysboot_D2F9A75E7F79C6DD-00-00.mrimg' to 'sysboot_D2F9A75E7F79C6DD-16-16.mrimg'
Failed: Failed to load 'O:\network backups\desktop-yjk\sysboot\sysboot_D2F9A75E7F79C6DD-00-00.mrimg' MD5 Checksum Failure - file is corrupt

An error has occurred when reading file 'O:\network backups\desktop-yjk\sysboot\sysboot_D2F9A75E7F79C6DD-00-00.mrimg'
Process failed
Successfully recovered from failed consolidation

This only happened once a couple of days ago, and it hasn't occurred again since. In fact, this particular imaging job was listed as successfully completed, and I normally wouldn't bother to look at anything unless it ended up as a failure. However, this "successful" job had this big glaring error inside it, which has me a bit concerned about it. What could have caused the checksum error? And how did it specifically recover from it? Did MR fully recover from it, or did it eliminate any section with corrupted data, and continued on with the rest? So is there a part of the backup missing from this file?

The backup drive is an internal SATA HDD, so it's not an external USB-related connectivity issue.

Successfully recovering from a failed consolidation does not mean that the image was repaired.  It basically means that Reflect was able to revert to the pre-consolidation state for both backups involved in the consolidation operation.  But that doesn't mean that future consolidations will work -- in fact the corruption was likely the reason for the failure -- and if you can't perform consolidations, then you can't purge older Incrementals.  And of course if Reflect is telling you that the Full backup is corrupt, you should create a new one asap anyway because that would mean that any new backups that depend on that Full would be useless.

A backup that includes a consolidation failure should show as having completed with warnings, not having completed successfully.  At least that would be the case if you're running Reflect 7.2 or newer.  But I see that you posted this in the V6 section of the forum.  Prior to 7.2, Reflect only had success or failure as possible outcomes, and in your specific case the job was deemed a success because technically the new backup was generated successfully.  The consolidation is what failed, and the Full being corrupt -- while a huge problem -- is not technically a problem with the new backup that was just created.  I actually personally lobbied for the new "warning" outcome introduced in Reflect 7.2 based on a few cases like this where a success outcome masked a problem that if I'd known about sooner I would have been able to correct more quickly.  But that wasn't backported to Reflect V6.

I did a verify of the main image, and it passed that. Also the error occurred about 3 days ago (only noticed it by chance today), and there were 2 other incrementals that went through properly since then, including their consolidations. The incremental that was supposed to have been consolidated and failed, is no longer there. Did it attempt to consolidate a second time and it worked, therefore the incremental image was deleted?

As for starting a new full image, yeah, that happens automatically anyways at the start of each month. I only do forever incrementals during the month, and then at the start of the next month a new full image is created, mainly because I really don't trust Forever Incrementals specifically for things like this might happen. So a new full image was created anyways this month.

Yes, MR v6 has some very weird logging behaviour.

So you did a successful verification on the root Full AFTER seeing that error?  I'm not sure how to account for that.  I run Incrementals Forever at a client, but they have a rotation of multiple disks.  And I also exchanged some emails and forum messages back and forth with Macrium Support before doing that, though, since corruption was on my mind.  I was impressed to learn about their implementation and the steps they take to mitigate both the introduction of corruption into the consolidated image AND maintain the ability to recover from consolidation failures even due to things like the disk being disconnected midway through the operation.  The only times I've seen unrecoverable consolidation failures have been when the entire drive had failed.  But I end up creating a new Full backup periodically even there because consolidation creates fragmentation within the root Full, and that isn't the type that gets fixed by defragmenting the volume.  That fragmentation causes consolidation operations to take longer over time.  So for example, early on an Incremental that took an hour to create would take another hour to consolidate later on when that happened.  Eventually I got to a point where an Incremental that took an hour to create could take 8 hours to consolidate.  Macrium says they're looking into how to optimize this routine to avoid that degradation, but I haven't seen anything about it since then.  That said, the Incremental backups where I'm doing this are about 150 GB apiece, and it doesn't happen until several dozen Incrementals have been consolidated into the Full.