What you as specifically talking about is a Unified Kernel Image, aka UKI (kernel + initrd/initramfs + stub + ...). It can be used as an actual "usable" system, where instead of `switch-root`ing into a mounted filesystem it just stays in the initrd. This is then refered to as a Unified System Image, aka USI.
The easiest way to execute a program in a UKI/USI is just putting it at /init which gets executed first if nothing is specified in the cmdline. So that is a way you can have it execute something. But initrd's are mostly read-only and would need to be extracted and repackaged if you want to add a file and also stops existing (for the most part) once `switch-root`ed, so I honestly am not sure if that could cover the possible intent behind such a mechanism described in the article (tho I also mostly just skimmed the article, so I very well might be wrong on that though).
What I meant with it is: there is probably a way to re-create it by extracting it from the UKI and using some form of overlayfs. It's not like the initrd in the UKI gets deleted lol.
The easiest way to execute a program in a UKI/USI is just putting it at /init which gets executed first if nothing is specified in the cmdline. So that is a way you can have it execute something. But initrd's are mostly read-only and would need to be extracted and repackaged if you want to add a file and also stops existing (for the most part) once `switch-root`ed, so I honestly am not sure if that could cover the possible intent behind such a mechanism described in the article (tho I also mostly just skimmed the article, so I very well might be wrong on that though).