That's an interesting situation... I am often asked to report on why a customer's RAID array behaved (unexpectedly?) in a certain way. However, something which few customers realise is that the data needed to understand
why something happened, is often destroyed by the changes needed to (hopefully) fix the problem itself! Therefore by the time I get involved, vital information that would be needed to find the cause of the original problem, has sometimes been lost. In short: all diagnosis must be done
before fixing the problem, because it may be impossible to do further useful diagnosis afterwards. IMHO that probably applies in your situation

There are a few parts of your posting where I think further detail & investigation of the original behaviour would be needed, to better characterise the underlying problem. Unless you still have a full hardware setup (original RAID controller, original disks, original software like Acronis etc.)
which still shows the original behaviour (at least regarding the disk/RAID-related problems), then there is no chance of understanding the original cause(s) with (near-) certainty. In your posting, I see two main areas of unusual disk/RAID-related behaviour during your testing, that would need to be investigated further at that time. However without being able to do further investigation and diagnosis on the original "failing testcase" then, looking at your posting and based on my previous experience, any suggestions of possible causes would just be untestable
guesses and hence easy for trolls to argue with and not really useful, nor worth the time.

At least you recovered the customer's data