I'm not sure how you'd manage upgrades - that's an OS function, but for nspawn you'd just write your unit file to Require some *.mount files before boot.
updates generally require a daemon restart (and in this case perhaps a container restart), if you couple it with requisite mounts, the whole machinery has to care for mounts, upgrades and restarts altogether
I suspect it could be hacked somehow with service files, too
This is particularly significant if you use something like btrfs snapshots with a base mount and child mounts, or overlayfs and invalidate inodes during upgrades, instead of a dumb-ish "yum upgrade/apt-get upgrade/etc"
The main difference is that in this case the update is at the mount / container level when propagated from the base image.
Some (most) others also do that with image versions and a full image swap.
I suspect it could be hacked somehow with service files, too
This is particularly significant if you use something like btrfs snapshots with a base mount and child mounts, or overlayfs and invalidate inodes during upgrades, instead of a dumb-ish "yum upgrade/apt-get upgrade/etc"
The main difference is that in this case the update is at the mount / container level when propagated from the base image.
Some (most) others also do that with image versions and a full image swap.