Atomic pathname replacement visibility across mount namespaces for zero-downtime redeploy

Goal is to redeploy a small user-space application without interrupting in-flight requests, relying on Linux kernel-supported atomic pathname replacement and mount/namespace operations rather than external orchestrators.

The design assumes rename(2) within a single filesystem provides atomic visibility for new opens while existing file descriptors continue referencing the previous inode. When the application root is exposed via bind mounts and the deployment uses move_mount in separate mount namespaces, propagation flags and kernel version determine whether the new location is visible to peer namespaces and to new connections.

The decision point is the consistency of visibility and propagation guarantees across namespaces and filesystems, especially regarding when a moved mount becomes observable and whether atomicity is preserved across bind mount boundaries.

What conditions make a rename-based swap reliably visible to new opens in a peer mount namespace? Is move_mount visibility governed solely by propagation settings or also by user namespace privileges? Does atomicity hold when the target path is reached through a bind mount in a different mount namespace?