The manufacturer needs to issue a recall in that case. They can't have their cake and then eat it too. Either the update is not critical and should not be generally available or it is critical and they should inform their users with the proper framing.
The original software will always have bugs in it, and those bugs will need correction. Software updates to fix/enhance it will also introduce new bugs.
The idea that one can create complex bug-free software is a fantasy. The correct mindset is to learn how to deal with failure. (This is how airliners are designed.)
> What if the update is to address a safety issue?
If they didn't make "safety" right from the first time, why do you think they will do it better the second time, when the fixes are more expensive and the time pressure is enormous ?
Hence the famous joke at NASA that you get to launch the rocket when the documentation if piled up would be taller than the rocket itself.
...all of which is just an excuse to show this great picture of Margaret Hamilton [1] lead developer on the Apollo guidance system standing next to (and slightly shorter than) the printouts of the source code https://en.wikipedia.org/wiki/File:Margaret_Hamilton_-_resto...
I've worked on some interesting software with lives on the line as well and the amount of test code absolutely dwarfed the functional part. I wonder whether at the time of the effort you linked that was already common practice and if it was what the fraction of that code was tests.
Assuming she's 1.65 meters tall and 66 lines per page (quite common back then), at 0.2 mm thickness per page that's 8K pages times 66 lines / page is ~550K lines. Pretty impressive!
The NASA space probes are constantly uploaded with new software that has greatly increased the scope of their mission.