The re-flash from a programmatic/computer sense isn't magic. It has been being done since the early space programs. A well designed system meant to be updated has a minimum of 2 locations for programs, A and B and the ECU can boot/load either one.
They typically leave the factory with both programmed to 1.0. In the event of a boot failure (depending on the error) the system can boot to the other side.
When an update comes out it is written to the side not currently in use. If it programs completely and the checksum matches, it will start using the new program. If it doesn't check out or crash during update it reverts back.
A lesser designed system constrained to only one program (money/storage/design are some reasons why) will operate similar with a critical difference, if it doesn't boot afterwards there is no fall back. These are very prone to catastrophic failure if power is removed while updating or the update is interrupted. Some have temp "b" sides to flash and after a successful reboot will then use the new one.
As far as the program goes based on the ECU and its revision number, it will be the same all the way around. Unless this is a VERY poorly designed ECU, you can't have a partial, or "different" flash, it either all comes in and the checksums match or they don't.
This rant isn't about the "program" or what it contains, just about how the updates and hardware generally work. What would make two sleds run differently after getting the same flash is most likely components, assembly, and environment. By components I don't just mean the sensors and ECU, but also the components that make up the ECU and sensors. Change a brand/model/alloy etc. in a temp sensor and it will react differently (timing as well as output). Mix and match electronic components (cpu/ram/resistors/caps etc.)and the variables stack up fast. Manufacturers always try to run in batches where all the components match however it just isn't possible to always keep everything the same. They don't make most of the discrete components so they have to rely on what they get.
We have run into all sorts of gremlins through the years with controllers and software. AAGR in our case software is software, it does the same thing each time, over and over. Don't get me wrong - the program has to be right because it will do the same thing WRONG over and over as well - but it will do it consistently. When things react differently between unit 1 and unit 2 when they are built the same it is usually hardware. Fortunately you can often get "around" bad hardware issues with good software - go figure.
My Viper2.0 (2015 XTX) came with the new flash and if I didn't stay on the key for a second after start, it would often have a kick back. I don't trust others on it just because of the start/kickback issue. Based on the fact that the flash fixed some issues while creating others tells me to count on a new flash coming.
