Thanks for your concern. Let us now and henceforth round up the nonsense and only post things likely to be of more general interest.

Possibly i you get the initial grub splash screen, you might try using E, C or ESC to enter grub command line and ther type "exit" and ENTER.

Please use "code" block around code and log files.

@alexkemp; late evening perhaps
Please check /etc/default/dbus again (which indeed is different from  /etc/init.d/dbus).

You might want to use the following setup variant:
First, create or edit  /etc/wpa_supplicant/wpa_supplicant.conf to have 2 initial lines like this:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

Secondly, change /etc/network/interfaces for wlan0 to read like this

auto wlan0
iface wlan0 inet manual
    wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

Thirdly, add the user to the group netdev.

Then that user can operate the wlan0 connection with wpagui (which you might need to install), and all details for networks that they connect to gets saved in /etc/wpa_supplicant/wpa_supplicant.conf, to be autimatically re-used upon roaming... (it's also possble for you to enter that beforehand with a text editor, but the file is also updated by wpa_supplicant. See man wpa_action for details).

EDIT: Note that there are two iface blocks for wireless in this setup. Firstly the wlan0 block that registers it to wpa_supplicant via the wpa_roam setting, telling the name of the connection database file to use. Secondly a default block that wpa_action uses for configuring the interface. Note that "default" is the name of that block.

EDIT 2: Technically this solves the issue of running a dhcp attempt too early to the wrong network by  the wireless setup being broken up into two phases. The first phase happens on boot, where the interface is brought up to link level. That enables wpa_supplicant to scan for available networks. The interface is thereafter raised to ip level when wpa_supplicant discovers a network it has connection details for, and then dhcp is used (as configured by the default iface block) with the approrpiate link encryption for aquiring the network address(s) etc.

This setup also allows for static (rather than dhcp) network configurations to be made for individual networks. You do that by other specially named iface blocks to identify the concerned connections. See the man page if you need that.

Sorry, I replied before I saw your edit... hmm.

According to man apt_preferences there is an automatic priority of 990 to the versions that belong to the "target release", which would be declared in /etc/apt/apt.conf or some file in /etc/apt/apt.conf.d by a line like APT::Default-Release "stable";
Comment out that line (with initial #)

Use apt-mark showhold to check if it's held or not.

/etc/apt/preferences.conf and files in /etc/apt/preferences.d/ define preferences.

And apt-cache policy openssh-server would tell about pinning as well.

You may want to include daedalus-proposed-updates in your sources.list
as well as daedalus-security

With ifupdown, bridges get set up by the /etc/network/if-pre-up.d/bridge script when that script detects that the iface block has a bridge_ports setting. That script is provided by the bridge-utils package which nowadays is "optional", so perhaps it's not installed?

Bridges are of course available as kernel networking elements regardless of that package, and the ip command operates on the kernel elements.

Generally speaking, the ifup and ifdown commands are tunable and extensible by means of scripts/programs in the /etc/network/if-* directories which all get invoked when interfaces are brought up or down by those commands. See man interfaces for more.

The ip command only operates on the kernel's networking setup and it does not make use of ifupdown. It's rather the opposite, that ifupdown scripts (and built-in functions) make use of ip to effectuate declared configurations.

You need to use Devuan's debootstrap (not Debian's).

Thanks, I think it does require coding though.

Generally a debconf dialog (set) is driven by a control script (typically an sh (dash) script) with successions of dialog building "commands", possibly in groups with intermediate decision logic. In this case it might be simply a single dialog for asking whether to use eudev or vdev, although designed so as to allow for expansion with further options. Then there would also be code for effectuating the choice at the appropriate time during an installation. I haven't thought about it in detail.

The debconf subsystem kicks in during package installation just prior to the processing of the postinst script. Thus this choice dialog software would be made as a package to be "automatically" installed so it then brings up the dialog. This would be similar to other debconf dialogs, and that is really the reason for implementing within that paradigm. I suppose the point is to fit it into the current installer framework which therefore requires a bit of learning about that framework.

There is also a point in that "hotplug handling" is kind of a forgotten concept area where a single solution (udev) has become unduly dominant whilst having grown into a rather opaque complexity. Perhaps one would be better off with something less opaque and complex?

Have we found the bottom now?
Or should I be less pessimistic?
Maybe jokes can always be worse...