So what, automotive developers never make silly bugs?
Case in point: Audi Concert/Chorus radios used in early 2000s. Turning volume knob worked like that: after every knob turn save updated value to EEPROM, then immediately read EEPROM and send that value to audio chip.
Inevitably, after many years EEPROM cells storing volume died, causing that turning volume knob just set volume to totally random value. It was impossible to repair, as EEPROM wasn't separate chip but was integrated in MCU. And you couldn't easily replace MCU because it contained mask ROM code. The hack that was sometimes done was: add custom microcontroller, connect it to the knob, splice I²C wires to audio chip, and patching volume set command on the fly...
The sad truth is you might be right. At a former company we had wear leveling in the firmware of IoT devices that would cost under 20$/piece so the fact that a car lacks such a basic feature, is shocking and tells me all I need to know about the development practices at Tesla.
As a firmware engineer with automotive background, having now seen how the "sausage" is made there makes me stay away from them for the safety of my own life.
I know the rest of he car manufacturers aren't as innovative or as desirable but at least some I worked for have their firmware development quality processes down to a religion, and, as boring as that may be, it's the kind of mentality you want from something you put your family into every day.
It did have wear leveling. They were just writing such an ungodly amount to it (more than the 8GB capacity) per day it defeated the purpose of wear leveling.
