The normal Debian/Devuan way is to establish a root account, and a normal user account. Assign a root password during installation different from the user password. Then you work normally as user, and do administrative stuff as root in a root terminal. This way you do not need this sudo stuff.

Even with a cli installation without any desktop, the command line tools for adding/modyfing users and groups will be present (see Delgados response). Downside: you need to log-in in a root terminal and do the work by typing.

Depending on the desktop you will find one or the other graphical tool, e.g. Cinnamon brings a limited user/group graphical tool.
Gnome-system-tools is the more convienent tool, I also add this tool to my installations sort of at the end of the fine tuning.

BTW: For a multiuser-installation I would go away from slim (which isn't maintained any more anyhow) and use lightdm instead. Or sddm for KDE, which isn't my personal preference.

The desktop permissions are typically set by policykit. Each desktop should come with some set of rules to allow for user access to removable drives in combination with group permissions.

Normal process, new stuff goes into sid at first, then eventually in testing, later into proposed-updates or backports.

239 is not in backports but in proposed-updates!!!

Thats why I am running Excalibur in VMs. Will keep that for a while ...

Don't think you will have many issues. SATA2 or SATA3 does not really matter, CPUs are of same brand and similar generation. The only issue could be graphics, especially NVidea. But if you are running Chimaera or Daedalus, the old stuff should be supported as far as integrated graphics is concerned.
You should be able to plug in the drive into the new MB and it should work.

Yes, the traditional setup requires an unencrypted /boot partition. I use that setup. In the encrypted partition I do setup a LVM with 2 logical devices for / and swap. /home always is on a separate device, except for in a VM. 

There is no need for special "early short command line detour for device mapping". You go through the installer step by step, and everything thats needed is prepared, no matter if legacy or efi installs.

With Arch Linux I could get away without that, but that requires a grub that can decipher luks2 and I think some tweaks inside of systemd.

You might consider that Chimaera even is too old for that laptop. Chimaera is oldstable anyhow, Daedalus is stable.

Go to Debian an bitch at them ...

No, running the usrmerge installation will become mandatory with Debian 13/Devuan 6. There is NO way to avoid this. Lots of fighting and bitching, but no help, its a Debian project decision, and they are pulling all roots for not merging now during development.

Running with Daedalus on my workstation, I have set up two VMs with Excalibur based on Daedalus cli installations about 6 months ago. My first step before changing the sources to Excalibur was to run usrmerge as it is recommended now in the documentation. And both of them work well.

You may have more luck when installing

# apt install libpolkit-gobject-elogind-1-0 libpolkit-backend-elogind-1-0 

This should remove the consolekit packages and install elogind stuff instead. And that should work.

Well, if you want a stable system with minimum hasle stay with Daedalus.

If you are ready for the unexpected, try Excalibur or Testing, and for the often broken, try Ceres or Unstable. Freshly updated/developed packages first land in Unstable, when they have sort of proven to generally work, they may be forwarded to Testing.

Testing some day becomes Stable, but currently this is about 2 years to go.

You only should use Testing if you are ready to accept uneven ground and if you are willing to contribute to this phase, or if you have a good reason to do so, i.e. you have so new hardware that its supported in Testing only. Something for the experienced user. And Unstable will be even rougher.

Just my two cents ...

I guess you are on amd64, a 64-bit system. Your application is a 32 bit application that requires a 32 bit library. You will need to enable i386 as architecture, if you haven't done so far, and then to install the 32 bit version of libcrypt1. Same procedure as for wine32.

# dpkg --add-architecture i386
# apt update
# apt upgrade
# dpkg -print-foreign-architectures
# apt policy libcrypt1