The 2021 version of relocatable was a prototype and quite reasonably wore the label of vaporware, but I’m pleased to say that everything presented at ICFP was (of course) very real. My development is rarely in private - anyone particularly interested to follow the workings of it, and the madness of my internal thoughts, can see my worklog for relocatable, various draft PRs on my OCaml fork (these exist to trigger CI runs on the individual branches), and the somewhat terrifying shell script which does the rebasing.
At present, I’ve got myself into the rather silly situation of two things being technically blocked on me - relocatable competes with getting the Windows parts of opam 2.2 finished, and I’m trying to focus on that at this precise moment (in addition to the list @gasche kindly assembled above 
).
As I noted just before the Christmas holidays in What are the biggest reasons newcomers give up on OCaml? - #73 by dra27, I’m intending to have the PRs opened in enough time so that there’s a chance to include it in 5.1, which means ideally the PRs should start appearing in late February. I’m not opening the PRs in bits until I have a complete “vertical” solution (including the opam packaging), because what’s happened at various points is that changes in a later PR require something to be tweaked in an earlier branch… this is why the various parts of it are all stacked together. As demonstrated on my fork, I also intend to propose that these be backported or possibly even back-released for 4.08+, so when relocatable lands, it will land for a considerable number of compilers at once. That increases the need for the patches to be battle-tested and utterly complete in advance.
This proposal makes opam switches less stable, not more so. At present, when you have bytecode executables built with two different switches, they are guaranteed to execute the correct runtime, but may (and do) pick up the wrong C stubs. Switching to using env as the first mechanism extends this instability to the selection of the runtime (relocatable uses env as a fallback mechanism, and uses name mangling to eliminate the risk of picking up the wrong runtime). I (attempted to) cover this in Slide 8 of my workshop talk (“Solution Part 2: Finding the right things”).
The failure mode of this is really bad - relying on environment variables to do this definitely decreases the stability of opam switches because we know from the bug reports, discussions, etc. that programs do get called with the incorrect environment. opam-repository already does a similar trick for CAML_LD_LIBRARY_PATH and it’s dreadful (see Only set CAML_LD_LIBRARY_PATH for system switches · Issue #16406 · ocaml/opam-repository · GitHub) - relocatable is meant to do away this kind of messing around with environment variables.