@JohnRusk are you working with blobs, files, or adlsgen2 blobs?

Hmmmm interesting. So quick summary of my findings today:

1. If not using AzCopy preview feature, then the download never finished. This is due to a bug in the Storage SDK. So maybe yours finishing despite the bad hash is related to that issue? Hard to tell since I can't repro what you're seeing. If you don't mind, I'll let you know once I have a version of the SDK that contains a fix -> I'll produce a private build of Storage Explorer with it -> you can see if you get the MD5 error.
2. If using AzCopy preview feature, there will never be an error. This is because we didn't enable MD5 checking yet for the AzCopy preview. We'll go ahead and make sure that is enabled for 1.8.0. 👍

Still waiting on the SDK team to release the fix. In the meantime, in 1.8.0, AzCopy will give errors if the MD5s don't match. Moving to 1.9.0 as I don't think the SDK team will make our release. =/

Thanks for the update @MRayermannMSFT.
Two quick points, for your info:

1. By the way, the approach we have settled on for AzCopy v10, when downloading, is that it should validate the MD5 if Content-MD5 is present on the source blob. We have an option to turn that validation off if desired - e.g. if a page blob has been mounted as a (unmanaged?) disk, it will never have a valid MD5 because its content gets changed after upload.

2. Maybe you should also be aware that, as of the current RC, which is 10.0.9, AzCopy defaults to NOT calculating the MD5 on upload. That's the opposite of previous versions of AzCopy and (maybe, I guess) the opposite of what Storage Explorer is currently doing.

@JohnRusk , when you say we, are you talking about yourself? Also, unfortunately we don't have the option/don't expose an option to disable MD5 (either on a file by file basis, or as an option present in say the download dialog). But it is something we will add when we get to doing settings (which should be soon?). And yep! I am aware of that behavior in 10.0.9. We've reacted accordingly and will always be adding the failIfDifferent option when running AzCopy. Hmmm maybe we should allow people to retry with that option off, similar to overwrite....I'll think about that!

@MRayermannMSFT, sorry, it's not clear from my signature. (Maybe I should fix that). I'm at Microsoft, working on AzCopy v10, and personally wrote the MD5 support.

We eventually will use AzCopy to replace our JS implementation for stability and performance. If we don't get the SDK fix before we use AzCopy by default, there is not much value to fix this bug. Our current AzCopy behavior is correct already, so won't fix this bug in our JS implementation.