Pardon me, but this seems pretty different from the use cases of DEP. Perhaps you'd like to expound further on this.
Imagine a standard webapp deployed via CI. Each time any feature is shipped the entire layout is randomized and then deployed. While a redundant system will have multiple copies with an identical layout, that layout will rotate. If required, a CI process could rebuild the system into N parallel groups with N different layouts (your degree of paranoia is the salt to taste here).
Given that these systems are frequently rebuilt with each deploy it seems nearly identical to me in practice to a relink-on-run.
lots of binaries are distributed as compiled, thats one of the attractions of a unikernel you can just hand people a VM image of whatever the hell you want.
In regards to what could be rebuilt, computer security is plagued with "coulds". What matters is what is done.
This is a tricky argument you make because it's so asynmetrical. You can essentially cherry pick the worst opsec and the most dedicated attacker and then use it to discount an entire technique.
I will not play this "Use OpenBSD because it has a new technique that is fashionable" game that I know is being played.
Custom baremetal custon built VMs is not really in the business of distribution appliance images. That's Docker. Different use case. So what IS done is a workflow to rebuild these images when they change.
And that's often. Their HTTP routing table is literally baked into the image. They're not "reusable" for the most part.
Imagine a standard webapp deployed via CI. Each time any feature is shipped the entire layout is randomized and then deployed. While a redundant system will have multiple copies with an identical layout, that layout will rotate. If required, a CI process could rebuild the system into N parallel groups with N different layouts (your degree of paranoia is the salt to taste here).
Given that these systems are frequently rebuilt with each deploy it seems nearly identical to me in practice to a relink-on-run.