It's proprietary, so who really knows?
"Negative feelings" about closed-source browsers and packages that are not compliant with Debian free-software guidelines or packaging policy, on the discussion board for a Debian-based FOSS distribution, are not particularly surprising.

That's really not a very high bar to pass, typhoid is "no worse" than lung cancer, but I for one don't want either.
Brave and the like are at least open-source, so any dubious "features" are readily inspect-able.

Everything is inline in the package postinst script, the repository configuration and key signature (base64, for reasons) are piped into the config files... Because of course that's how they do it - it's the best way to fuck around with the system (making sure their browser is the very highest priority in alternatives for example) and "support" multiple distros with a single .deb.
The crontab file is a symlink to /opt/vivaldi/cron/vivaldi, which is a copy-paste from the postinst and apparently rewrites the apt configuration and keys every day... Again, reasons, presumably.

Proprietary vendors are all the same when it comes to packaging, total disregard for established standards. Everything that can be an executable script is, windows lets vendors screw around however they like and execute whatever they want so that's how it must be done everywhere.

OP has 3 topics at this point, all whinging, and all full of the above.
Apparently any configuration choice (so far: root filesystem, partition layout, network configuration tools, boot media, DNS server / protocol, terminal emulator) that doesn't perfectly align with their preferences is some sort of "showstopper" disaster and/or conspiracy.

Is for you to:
a) Grow up, and realise that this is not Arch, it's a stable, general purpose distribution under no obligation whatsoever to embrace the newest shiny thing or cater to your peculiar tastes.
b) Post your commands and any "bunch of cryotic[sic] errors" encountered, verbatim and without shouting. Assuming you actually want assistance that is.

No, this is a bunch of whining and factually incorrect nonsense. Bug reports are submitted with reportbug or by email.

Specifically, no. I never cared enough to look into it. More generally:
There are about 50 different ways to build a bootable hybrid image, and most of them rely on the initramfs being able to find and loop-mount the image somehow.
That mechanism (and what kind of device and/or filesystem is searched) varies widely from one distro to another. They are looking for their image in their format on their filesystem... Not whatever "USB Maker 3000" decided to do.
Ventoty has a bunch of special-casing hacks to make this work, just not for Devuan.

The image boots fine from a raw device as intended, so this is a Ventoy problem for Ventoy to fix... If anyone actually cares that is.
Multi-boot USB drives are a hack, they've always been a hack, and it's not really on iso builders to pander to them.

Sure, but you'll need better bait to nerd-snipe me on that one. Bootloaders and initramfs scripts are tedious to test at the best of times, and 'need install media (once every 5 years at best)' x 'too lazy to fish out an old  $2 4GiB USB' = 'nanoscopic fleck of motivation'.

Bullshit.

Complete and utter bullshit.

Yes.

The installation image is ISO-hybrid, you're supposed to write it directly to a block device.

There's wrong, and then there's fractally wrong.

You are mistaken. Follow the instructions and write the .iso to an unformatted raw block device or optical media with dd or wodim.

If you insist on doing your own thing WRT install media and filesystems, because "other distros, blah, blah", that's up to you... And you get to keep all the pieces when it inevitably doesn't work.

Main memory latency is measured in nanoseconds, while even the fastest NVME SSDs are in the tens of microseconds. On older storage technology the gap is considerably larger.
An order of magnitude is "not noticeable"? That must be why Solaris started putting /tmp in RAM around 1994.

We're talking about Debian turning this on by default, not forcing you to use it. The vast majority of Debian (and GNU/Linux in general) deployments are servers, where 32GB is generally considered low-end. Setting the default to suit that use case while having minimal impact** on everyone else is perfectly reasonable.

Most mobile phones have more than 4GB of RAM these days, if you want to use antique hardware, that's cool... But expecting defaults in a general purpose distro to be tailored for that is ridiculous.

**
Devuan server, manual max size set, 38MB used:

tmpfs            2.0G   38M  2.0G   2% /tmp

Oh noes, 0.03% of precious RAM wasted on my 14 year old hardware.

My Gentoo desktop does not currently have /tmp in RAM, because I have a tendency to compile stuff there and old (bad) habits die hard.

It's optional, same as it always was:

# mount /tmp as a tmpfs.  Defaults to no; set to yes to enable (/tmp
# will be part of the root filesystem if disabled).  /tmp may also be
# configured to be a separate mount in /etc/fstab.
#RAMTMP=no

They "come up with this", because it's a thing many other distros do by default and many users used to do manually, which reduces SSD writes and improves latency for applications that make frequent use of /tmp.

"50% of my ram" is a default upper limit, actual memory consumption for tmpfs (unlike a traditional ramdisk) is dynamic.
On most systems /tmp is only a few MiB, and has negligible impact on available memory. If you want to stash huge files there for some reason, simply disable or configure it to your liking. See man tmpfs(5). Note that as per FHS, /tmp is not expected to survive a reboot either way.

/lib/init/tmpfs.sh, which is called from /etc/init.d/mountall.sh, which is illuminated by a couple of seconds with grep. I'm not sure what the big mystery here is.

"Quality control" WRT Debian and/or Devuan releases isn't about upstream software having bugs or not... It's whether buggy upstream versions are packaged for stable.
This is why we have the unstable -> testing -> stable workflow - packages that have serious bugs shouldn't be making it through testing... And they sure as hell shouldn't be the first thing a user interacts with in a release livecd or default install.

This particular bug in SLiM was raised in the excalibur RCs, and hasn't been satisfactorily addressed (nor has the one I reported). Those bugs existing is on upstream, but SLiM still being the default greeter despite them is a Devuan decision, and by extension, a Devuan problem.

Upstream bugs are not a distribution issue. Software selection, packaging, and sane defaults are.
If Devuan wants to package a different default desktop setup from Debian, the lack of QC on that setup is not something that can be blamed on Debian.
They use lightdm for their XFCE live image, did anyone think to ask why, or are we all too busy trying to deflect blame for the rushed, poorly tested, perpetually janky live releases?

SLiM is a mess, and has been for years. Stop using it as the default greeter. Problem solved.

03: Probably chipset power management. You don't say what (if any) sound server you are using or provide any details of your audio hardware, so generic answers assuming pulseaudio it is: here, and here. TLDR: Disable audio device PM, first for the sound server, and if that doesn't solve it do the same by passing the relevant parameter for (whatever hardware you have) as module options or via sysfs.

09: Again assuming pulseaudio: get sinks with 'pactl list-sinks', put 'set-default-sink [index you found with pactl]' in /etc/pulse/default.pa (see e.g. here)...
Or use a less gimped DE that has a GUI for configuring this and persists settings across logins.

If you're running pipewire the answers are similar, STW for correct config syntax.

10: If they're standard keys (i.e. not some vendor-specific nonsense), get the scancodes with xev - then assign them to do something with XKB or xmodmap... Or use a less gimped DE which supports media keys directly and provides a GUI for configuring them.
If they are special vendor-specific voodoo (i.e. xev doesn't spit out a scancode), they might emit ACPI events instead - for which there is acpid.

The rest: All XFCE problems. I don't use XFCE, I don't like XFCE, and I have no idea why it is the default desktop since it's not even particularly "lightweight" these days.

No.
That said, a) You needn't worry about data loss because anyone with a shred of sense has backups, and b) It's far easier to simply disable the port in BIOS.

I wanted something that I could put my Auzentech card in (because excellent sound quality, socketed opamps, sufficiently high output level to directly drive power amp without needing a preamp), that means a 32bit PCI slot, which means kinda old (i.e. ~sandybridge).
Ended up with *goes to look* an HP RP5800, which being a POS machine has the added advantage of powered-USB (12 & 24v) so I can do power+data for the touchscreen with a single cable.

Mopidy/MPD control is via webui (local touchscreen or remote), android app, or cantata on another PC. Sources are FLAC files over SMB from my (also Devuan) fileserver.
IMO a HiFi is for music (also, I haven't owned a TV for over a decade), so this setup does exactly what it needs to do and no more.
I did play around with a raspberry pi + DAC hat, but frankly the Auzentech just sounds better (primarily because it has real analog volume control).

I don't really do the brand-loyalty (excepting a minor soft-spot for '70's Sansui, reminding me to get on with fixing that AU9500) or "big name / big money must sound good" bit, I just mix and match what works and let my ears (and when it comes to amplifiers, my 'scope) be the judge.
I honestly have no idea what that 350W amp cost me to build, but it's probably getting up around a couple grand... A price worth paying for something with that much grunt and the ultimate (I built it, so I can always fix it) in serviceability and simplicity - No frills, no digital nonsense, just power and line-level in, speaker level out, a power button and one status light.

The rest is an assortment of opportunistic mostly second-hand purchases, dumpster-diving, and "screw it, nobody makes what I want, I'll just build it".

I don't know how you survived going from a 3K hifi to a portable bluetooth speaker, that sounds kinda painful TBH. If it's space at a premuim... Do speakers not take priority over bed, chair, kitchen table, other optional furniture?

More like several "USB stick"s in RAID0, with dedicated DRAM cache (or host RAM cache if you're a cheapskate) and a far more intelligent controller.

Usually, though what it's called varies by manufacturer.

Assuming it reads data from the usual sources, I don't see why not. Honestly I have no idea why people want some dedicated tool like hddtemp just to print data already available in sysfs or via smartmontools.