So, the process documented here appears to generate an artifact that will OTA update a previously deployed <warrior installation, resulting in an updated client/arti and a dual fs configuration, which is the intention. Perfect.
However, all the file system images generated for that same release, the ones that end up burned to bare metal during manufacturing, will not implement the dual fs config, they will continue to use /etc/mender/mender.conf, exclusively.
This results in a single version being released that is functionally different depending on whether it is deployed OTA or programed to a reel of chips during manufacturing.
Devices with the release programmed during manufacturing can not be OTA updated if the migration directives are removed from local.conf in future build/releases, despite that being the prescribed process.
If you would like to know what this looks like in practice, I can describe how this played out for us.