Do the simplest thing that could possibly work

I disagree. You prototype the simplest thing that could possibly work. Then, you design stuff so that you don't end up regretting it later.

I happen to have a recent example with an add-on card. For reasons that I won't get into, we needed both insurance against major rearchitecturing, as well as leverage synergy with other product lines when it comes to configuration. That led me to design a fairly intricate library that runs visitors against a data model, as well as a mechanism where the firmware dumps its entire state as a BSON document in a dedicated Flash partition before upgrading. That gave us the peace of mind that whatever happens, we can always just restore from that document and nuke everything else when booting a newer firmware for the first time.

The simplest thing that could possibly work would've been to not do any of that and let future firmware versions deal with it. Instead, I designed it so that I don't end up regretting it later, regardless of how the product evolved.

The only point I do regret was missing one piece of information to save on the initial release-to-manufacturing version. I had to put in one hack that if the saved document has version 1.0, then go spelunking in the raw flash to retrieve that piece of information where it was in version 1.0 and slipstream it into the document before processing it. Given the data storage mechanism of that platform, I'd be tearing my hair apart dealing with multiple incompatible data layouts across firmware versions if I did the simplest thing.

I think your version _is_ the simplest thing that works: software updates are part of what needs to work in embedded. else you brick devices and have to send technicians to the device, right?

The simplest thing that would've worked was for the initial firmware to do nothing besides putting the new firmware in the secondary slot, tell mcuboot to upgrade and then reboot. That shifts the responsibility of working upgrades to later firmware revisions, at the cost of significant technical debt and extra development costs in the future.

My point is that the simplest thing that could possibly work disregards state and time as factors. Good engineers balance all requirements to derive the simplest solution that works; great engineers do so while avoiding visits from irate future colleagues.