I do not think libsystemd0 is harmful

Yes, it is just an annoyance but removing it would be wasted effort for no benefit. That's why it may still present in Devuan.

Unless something has changed, there is no need to have libsystemd0 present in Devuan.

I misunderstood the sticky on systemd mentioning libsystemd0 being used sometimes to determine if systemd was running, and thought that this package was necessary, so I tried to use the dummy-elogind, but this would not allow some packages that were part of task-mate-desktop, so I had a partial de install and dummy-elogind. Fortunately, I figured it out when I looked into what would break when I removed libsystemd0. My wifi applet does not work (that is okay; I don't necessarily need a gui for it as long as it works), but I followed the excellent guide by quickfir and got it working (the only difference was I had to use apt-file to locate iwconfig and ifup... now they work). If I have time next semester, I may try to edit the applet to get a gui method for this workaround.

apt list --installed | grep sysvinit-core
apt list --installed | grep systemd

Obviously, there should be sysvinit-core and no systemd. Then:

apt update
apt -s upgrade
apt upgrade
apt -s dist-upgrade
apt dist-upgrade

usually did it (without forcing or expicit de-installs).
The apt -s lines are optional. They do a simulation to spot problems. It might be tricky to solve dependencies in an interrupted migration.

Some programs will be de-installed during migration, so there is stuff to re-install.
And optional clean-up at the end: apt clean and/or apt autoremove

--
PS: Booted installtion with sysvinit:

$ ps ax | head -2
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:00 init [2]

In case of systemd: PID 1 is "/sbin/init"

Network-manager most likely needs updated configuration after migration (see below).

--
Remembering the migration of my notebook to chimaera:
One thing that happens during migration is: The network-device's name changes (from forgotten) to "wlan0" in case of wifi.
The network-manager's config files were still pointing to the prior device name. This was the reason for "no network connection".
The alternative to reconfigure network-manager was to restore the prior network device names:

# echo 'GRUB_CMDLINE_LINUX="net.ifnames=1"' >>/etc/default/grub
# update-grub
# reboot

Using update-grub may or may not be a bad idea in your multi-boot case.

startpar: services returned failure: nscd network-manager . . . failed

* octave is upgradable but not upgraded since I edited the .deb from the debian repo to remove the gui since I use geany for it and have no qt except on the neon install; I highly doubt this has any effect but am telling out of precaution

Now, what would be the safest way to continue? I chrooted into it to get that list of upgradable and not upgraded packages (I'm lazy and didn't write it down), and could install that way, similar to installing enough packages to set up wifi on a debootstrap-install. Alternatively, I could download the remaining packages and install them when truly booted into that install (well, efibootmgr will say I'm booted into neon since I'm using this grub to avoid ambiguities for the time being, but I assume it is okay since grub gets me in the correct one). I do not like the other options of using the clone or cloning the clone over this attempt, because I want to keep at least one working debian/devuan install at all times and cloning takes a day and a half. Is it safe to continue the migration from a chroot (since I already rebooted), at least enough to get wifi working? This is my preferred method as it is easiest.