The first "point of call" for packages could be like:
  https://pkginfo.devuan.org/systemd-boot
  https://pkginfo.devuan.org/systemd-boot-efi
Those packages are in the repo without forking since chimaera.

Fair enough; though that storyline that "systemd fixed something unsustainable for developers" is and was just plain marketing speech, and it's far off any reality. But the proponents sure filled the web with that thought so it's voiced failry commonly.

Yes Xorg has gone through a couple of steps through partially defunct versions. This originates in the sudden fork need when debian tied Xorg to systemd as way of supporting the use case of "non-root process owner without direct access to input device nodes". The solution was to interact over dbus with logind for mediating input access  and thereby draw Xorg into the systemd  web of entanglement.

The immediate fork remedy was to instead use libseat and offer the alternatives of using seatd as well as logind (over dbus) for input mediation, as well as including a "built-in" variant for system cases where the non-root user does have direct input access.. This forking task has taken a couple of iterations to stabilize. Supposedly it's now in good working condition.

A quick glance at https://pkginfo.devuan.org/libdvd-pkg tells us that the package is in the contrib section.

daedalus

Package: iw
Recommends: ..., wireless-regdb, ...
--
Package: iwd
Recommends: ..., wireless-regdb, ...
--
Package: network-manager
Recommends: ..., wireless-regdb, ...
--
Package: crda
Depends: ..., wireless-regdb, ...

It might be worth to clarify here that "Devuan" is not an organisation that wants you to run particular software.

Devuan's contribution to the Linux world is to provide a package repository that includes all Debian packages as is, expect for those needing forking to avoid the systemd infestation.

If you find a bug in the openrc packages (which are not forked) you may report that to the Debian bugtracker.

Though your issue might rather be in the combination of packages you have installed and you are right to raise it here as this Devuan community may well include people who also use openrc packages.

Afaict there are two packages competing about the /usr/bin/python pathname, namely packages python-is-python2 and python-is-python3.

I think the upshot for this was that python3 changed a lot in syntax as well as in data representations from python2 and at that time it was considered wrong to use the plain "python" in their she-bang. In support of that the python installations stopped committing to that version choice and instead offered the choice as different packages.

Apparently some desktop environment(s) might want to make that choice for us, but technically it remains a user choice in Devuan daedalus.

I can't help you for runit, but I'm very interested in learning how to de-brick after an attempt to move the OS onto the eMMC.

Note that the VT switching patch for xserver-xorg-core has been applied for daedalus.

A normal upgrade brings it in, if your sources.list includes daedalus-proposed-updates.

This was kind of convenient for me as I have very recently migrated to daedalus myself and hadn't yet set up bluetooth here. To do so, I did as follows:

# apt-get install --no-install-recommends alsa-utils blueman bluez-alsa-utils

That provides a virual soundcard named bluealsa for alsa, and this uses dbus to obtain the headphone "sink" from the bluetooth device management (actually bluez) with blueman as a handy GUI tool for operating the bluetooth devices.

bluez-alsa-utils unfortunately installs as if systemd would be around, so some additional hands-on is needed for registering the bluealsa dbus service. You need to add the following text file:

Then you run blueman as non-root user for the device management, to pair and connect the headphones. (Keep it running in the background, though if it works well it install a control button in the panel)

Note that you need the mac address for the headphones for playing to them. (E.g, after pairing you can bring up the "info" page for the headphones by right-clicking, and there select and copy the "Address" line for later pasting).

For testing this you may try the following (with your mac address rather than mine):

$ aplay -D bluealsa:30:21:DC:50:9E:89 /usr/share/sounds/alsa/Rear_Center.wav

Next, if you want to direct audio to bluealsa by default, you may state that in your ~/.asoundrc, eg:

pcm.!default headphones

pcm.headphones {
    type bluealsa
    device 30:21:DC:50:9E:89
    profile a2dp
}

There's a lot to be known about alsa configuration....

If "Installed Daedalus" actually means "dist-upgraded to Daedalus" there is the possibility that you overlooked adding the (new) non-free-firmware section onto the sources.list lines.

Other than that, I don't know much about nvidia cards.

You need firstly to install bluez. This package and it's sub packages handles the actual connectivity between the computer and the headphones. Conceptually bluez represents the computer endpoint for the "wireless wiring' to your headphones.

In addition to that, you need the pieces of software that links the sound system with the bluez device management. This part depends on which sound system you are using.

Plain alsa or pulsaudio are possibly the two main alternatives for audio setup, but there are others.

For plain alsa you would need the bluez-alsa-utils package which implements the "virtual soundcard" that plays to and records from bluethooth headsets. It will also need manual configuration changes to tell the sound system how to channel audio through it.

For pulsaudio you instead would need the pulsaudio-module-bluetooth package. Upon installation it updates the pulseaudio configuration to some extent but there might also still be additional hands-on needed. I no longer use pulsaudio though so someone else will need to guide you for that.