From the paper > There are three specific limitations to multiplexing, at present. First, the benefits of multiplexing are limited to a predetermined set of ap

From the paper > There are three specific limitations to multiplexing, at present. First, the benefits of multiplexing are limited to a predetermined set of applications combined together, unlike either shared libraries or Slinky, both of which share code across arbitrary applications on an end-user’s system. As noted earlier, combining multiplexing with Slinky would get both kinds of benefits. As a direct consequence, sets of applications to multiplex must be predetermined, cannot be varied from one end-user to another, and adding new applications to an existing set is difficult (short of replacing the entire multiplexed binary for the set). Second, multiplexing makes it difficult or more cumbersome to update software by upgrading or patching dynamic libraries. Third, the current design of multiplexing disallows introspection techniques like the use of dlopen and dlsym. So yeah, this is not something the distros could use, you would have to ship libs in allexe format(essentially llvm IR). It seems their motivation is systems running a fixed set of binaries on production server allowing some nice memory/disk usage reduction.