As far as I understand, Vdev goes beyond being an alternative to
Systemd-Udev: it also aims at providing the possibility to give a
per-process view of the device special files - I personnaly haven't any
need of that. Its implementation differs strongly from Udev, which makes
it necessary to have a different library for applications (libudev-compat).

     For what regards complexity, I cannot tell which one is the most 
complicated. The biggest problem for me is that none of these tools has 
set an obvious standard on how to pass information from the hotplugger 
to the applications invoking the library. Another issue is that the 
library provides functions for the use of the hotplugger itself and 
functions for external applications, and it is not obvious which subset 
is destinated to external applications.

     Mdev (Busybox), on the other hand, is much simpler and has 
significant advantages for small systems, but it does not interface with 
a libudev, which is a problem for some applications, like X.org when it 
is running without config files.

     I mentionned Mdev here to try give a complete view and because it 
makes sense in a minimal install. It would make sense to provide all 3 
systemd-free hotpluggers in Devuan, if possible, for freedom of choice.

     For what regards initramfs, AFAIU the packages involve an initramfs 
part, which means that they insist on having the very same hotplugger 
running during the initramfs phase and after. If the hotplugger is 
restarted when entering the final rootfs, then I don't see any need for 
having the same one before the pivot-root or switch-root. It would be 
simpler to run Mdev in the initramfs. I have done this already on custom 
debian systems.

     Didier