Please don't say that. Users don't reflash the FPGA. FPGA's lose their memory on power-down/reboot.
The system loads(I.e., programs) the FPGA via SPI Flash. The CPU can send a *.bin to upgrade that flash so it loads it subsequently.
Not 100% sure about that.
System indeed program program SPI flash, but only some part.
I have checked before and SPI flash content was matched with boot and selftest bin programmed by system but area starting from 0x0 is not matched with anything.
It may be a different version of firmware or maybe not and firmware is different.
Agreed, it's hard to tell what that 0x00 bit is/was supposed to point at.
My hypothesis: they have one "working", one "update" and one "factory" copy of the FPGA configuration.
It used to be standard practice in embedded designs I worked on, to keep multiple copies in case an update goes bad. If the update is good, and boots normal, then the "working" and "update" copies can be revised. Then a "restore to factory" copy hidden away that can be restored in case of corruption, etc. Saves on tech support inquiries and RMA's.
I'm not sure exactly how Rigol chose to do it., but I think you proved that they loaded the SPI with multiple copies. I remember thanking your post.
And then; This could just be Rigol software guys not cleaning up behind themselves. They have multiple copies of files littered everywhere on the SDCard.