FWIW, I've been running unattended-upgrades on several machines for over a decade, and have no significant borkage (aside from a recent Devuan identity-crisis SNAFU with unattended-upgrades itself) to report.
Then again, the only machines I don't have convenient physical access to have IMPI. If SSH was the only way I could administer a box, I'd likely be doing updates manually... Or at least restricting unattended-upgrades so it doesn't touch anything critical.

AKA, lots of preaching with very little doing.

In many cases these frameworks are already optional, via compile-time flags... Something which, for reasons that apparently escape me, you seem completely unwilling to consider.
Where they are not optional at compile-time, patches to upstream code would be required.

There is no standard facilty for making dynamic-linked library dependencies optional at runtime, because that's not how any of this works. The thing that is becoming most tedious of all is your insistence that there shouid be such a feature, and somebody other than you should see to it.

If you want everything built for you and served up in convenient packages, you get whatever the packagers decided on when they built them (or engage in constructive discussion where you disagree).
If you want control over compile-time options and patches, you run Gentoo or some other source-based distro.

Anything else is just blowing smoke. The tools to build a system the way you want already exist, if you're willing to put in the effort to use them.
Have you actually built and used a system without dbus and policykit, or is this all just idological bikeshedding?

All that said, if you want to be taken even remotely seriously on the idea of making such dependencies optional at the package management level (which would entail binary distros maintaining multiple variants of each affected package):
* What is your convincing technical argument for such a change?
* What do you propose replacing the projects on your "evil" list with? You want to drop dbus for example, so how should we do IPC?
* And, how is your proposed replacement (functionally) superior?
* How do you propose convincing 1000 upstream projects to drop features dependent on $evil_library or switch to your replacement?
* Who is going to do all this work, and does the benefit justify it? If upstreams aren't on board, who is going to write and test patches?

... Or NixOS, Gentoo, CRUX, Gobo, FreeBSD, or any other system that provides tooling to build packages locally with the configuration you want.
Were you motivated enough to do so, this can also be achieved with Debian/Devuan... It's just a bunch more work as the packaging tools don't really cater to global feature switches the way e.g. Gentoo USE flags or the nixpkg declarative build system do.

What you're really asking for appears to be a binary distribution where all the configuration and packaging work is done for you, yet the choices the maintainers make are precisely aligned with your preferences... That's not going to happen, regardless of how much you complain about it.

You want the Devuan developers and maintainers to fork and rebuild everything to run without $things_you_dislike, yet you're not even willing to properly define what you want or what would be needed to achieve it?
Not to put too fine a point on things: Get off the grass.

Personally I have no problem with library dependencies and dynamic linking, where it adds legitimately useful functionality and reduces code duplication.

But that's not what this is. Supporting sd_notify is little more than sending a simple datagram to a unix socket, and pulling in libsystemd0 for that one function is just about the definition of gratuitous attack surface.
But hey, why not double down, ignore the fact upstream has already said no because they don't want the dependency bloat, and go and patch it in regardless. The "systemd exists, so everything should use it somehow" bandwagon must grind ever onward.

Then there's that other obvious elephant of course: why does init need an LZMA (de)compressor anyway? Init's job is managing daemons, nothing more... Right?

IMO far too many projects pull in dependencies because it's the easy way to implement a feature, with precious little regard for whether it's a good way... or whether that feature is even worth having to begin with.
That includes distro packagers turning on every optional build-time dependency flag they can find, which is a long-time gripe of mine WRT Debian. Patching upstream sources for even more dependencies is just taking this trend to its (il)logical conclusion.

64bit time transition.
Now is not a particularly good time to volunteer your main rig as a testing/unstable guinea pig, at least not if you want to get anything (besides being a guinea pig) done.

sshd in daedalus depends on libsystemd0, which may be satisfied by either the real libsystemd0 or by libelogind0 and libelogind-compat.
The former results in sshd being indirectly linked against liblzma as it is in Debian (though I'm not sure if that alone is enough to allow the exploit), the latter does not...

So effectively, both comments are correct depending on the exact set of packages you have installed. Devuan does pull sshd from Debian, so it does link against libsystemd. However the stripped-down copy of that library provided by elogind doesn't load liblzma, because its systemd-notify functionality is a stub.

In any case this is largely academic, as daedalus never shipped the compromised xz versions.

More accurately, targeting sshd (so far, anyway) via a vulnerable understaffed/funded project which just happens to provide attack surface because certain distros patched a security-critical package to add gratuitous linkage to systemd.

This is not about diversity, or even systemd specifically. It's about dependency bloat.

There is zero reason sshd needs to link against anything in systemd, let alone pull in liblzma just to support systemd-notify (and linking a full blown compression lib just to say "sshd is up" to systemd is another level of insane to begin with). Doing this kind of thing opens it up not only to vulnerabilities in such direct dependencies, but also the 9000 other frivolous things those in turn link to.

This is a perfect example of why anyone serious about security resists bloat and feature-creep. Without the ridiculous "because it's there" attitude of the distros involved (particularly WRT systemd integration), this exploit would not have been possible.
If sshd really needed systemd-notify support (and it doesn't), it should have been via a minimal implementation in sshd itself, not pulling in a bunch of bloat and a compression library essentially maintained by one dude.
Distros patching this kind of stuff in downstream is, frankly, pretty irresponsible.

For a quick illumination of just how out of hand this is getting in Debian/Devuan...

$ cat /etc/os-release; ldd /usr/sbin/sshd 
PRETTY_NAME="Devuan GNU/Linux 5 (daedalus)"
NAME="Devuan GNU/Linux"
VERSION_ID="5"
VERSION="5 (daedalus)"
VERSION_CODENAME="daedalus"
ID=devuan
ID_LIKE=debian
HOME_URL="https://www.devuan.org/"
SUPPORT_URL="https://devuan.org/os/community"
BUG_REPORT_URL="https://bugs.devuan.org/"
        linux-vdso.so.1 (0x00007ffc96fde000)
        libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f27a6768000)
        libwrap.so.0 => /usr/lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f27a675c000)
        libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007f27a672b000)
        libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007f27a6719000)
        libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f27a6649000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f27a6619000)
        libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f27a65c7000)
        libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f27a64ed000)
        libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f27a64e7000)
        libcrypto.so.3 => /usr/lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f27a6000000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f27a64c8000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f27a5e1f000)
        libnsl.so.2 => /usr/lib/x86_64-linux-gnu/libnsl.so.2 (0x00007f27a64ab000)
        libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007f27a64a3000)
        libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f27a6497000)
        libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f27a5cd8000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f27a5ca9000)
        libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f27a5bed000)
        liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f27a5bc7000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f27a68ec000)
        libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f27a5b2d000)
        libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f27a5b00000)
        libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f27a6487000)
        libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f27a5af9000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f27a5ae8000)
        libtirpc.so.3 => /lib/x86_64-linux-gnu/libtirpc.so.3 (0x00007f27a5aba000)
        libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f27a5a92000)

$ cat /etc/os-release; ldd /usr/sbin/sshd 
NAME=Gentoo
ID=gentoo
PRETTY_NAME="Gentoo Linux"
ANSI_COLOR="1;32"
HOME_URL="https://www.gentoo.org/"
SUPPORT_URL="https://www.gentoo.org/support/"
BUG_REPORT_URL="https://bugs.gentoo.org/"
VERSION_ID="2.14"
        linux-vdso.so.1 (0x00007ffd3cde1000)
        libcrypt.so.2 => /usr/lib64/libcrypt.so.2 (0x00007f18fdd74000)
        libpam.so.0 => /usr/lib64/libpam.so.0 (0x00007f18fdd63000)
        libcrypto.so.3 => /usr/lib64/libcrypto.so.3 (0x00007f18fd800000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00007f18fdd47000)
        libc.so.6 => /usr/lib64/libc.so.6 (0x00007f18fd62f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f18fdec5000)

Which of these do you think has the larger attack surface, or more vulnerable supply-chain? I'm not even trying with that Gentoo build, and I could easily drop pam if I did.

Ahh the old hydrgen drum...
* Extremely low energy density.
* Requires exotic tankage or cryogenics for any attempt to overcome (1)
* Is very, very energy inefficient to produce by any current "green" process (which is why most industrial hydrogen is produced through reforming natural gas).
* Is a complete bastard to work with, as it's low molecular weight means it leaks through just about everything.
* Is arguably more dangerous than either petrol or lithium-based batteries, due to its broad explosive range.

If you want to use solar to run a car, frankly you're better off with batteries for most use cases.

Tell that to people who need to move a couple hundred Kg of tools and equipment for their job... Or travel from outside of urban centres... Or have more than one child... Or a disability...  Or point-to-point freight in general for that matter... Or any number of other situations where tiny vehicles or bicycles are completely inappropriate.

"Pedal power" is part of the solution. It's a long way from the whole story. Likewise rail and electrified public transport.
Just continuing to shout "everyone needs to get on a bike" is exactly as effective as "everyone needs to get an EV", all it does is make transport of everything too heavy or distant to put on a bicycle somebody else's problem.

Driving a 2-ton SUV to get milk is patently ridiculous... But so is insisting that everyone should ditch their private vehicles and "just get a bike".

Indeed. Even leaving out the electric part and comparing diesel trains to diesel trucks it's no contest.
What trains can't do however is roll up outside your house with whatever tat you ordered on amazon 2 days ago. The current lazy online shopper generation is fuelling road transport pretty hard right now.

As ever, what people really want is a "Buy now and fix climate change"/"Spend and feel morally superior" button. Big corporate (and EV manufacturers) are of course all too happy to oblige, and governments to turn a blind-eye to how ineffectual all that is so long as they can be seen to be promoting something with a nice thick coat of green paint on it.

Meanwhile the real elephants in the room (of which private transport is decidedly small-fry) go conspicuously unnoticed, and the solutions we do have go unimplemented, largely due to being expensive or inconvenient - either personally or politically.

Electric traction? Sure. We've had that in various forms for ages, and advances in battery technology have now made it viable (if still a mite explodey) for the private automobile.
Electric traction as the solution to anthropomorphic climate change on the other hand... That's just another episode of the same old consumerist "magic pill" bullshit... See quickfur's excellent coverage above.

Now, that's not to say I wouldn't want to own an electric vehicle. They do have some advantages, particularly where relatively clean electricity is cheap and charging infrastructure isn't woefully inadequate.

However... As far as I can see, it's next to impossible to really own any modern vehicle, regardless of powerplant. So if someone would like to point out an EV that isn't a rolling spyware platform full of obnoxious "safety" features designed explicitly to piss me off and prevent my vehicle from doing what I tell it to, I'm listening...
Otherwise I'll stick to my simple, obedient '70s and '80s tech. No cameras, no GPS, no manufacturer phone-home or remote killswitches, no feature subscriptions, no touchscreens, no driver attention monitoring, and most important of all, no goddamn incessant beeping about every trivial thing.

As for fission vs (fossil fuel) combustion, "clean"ness and timescales... Sure. The only missing component there is that we have some viable solutions for processing and containing spent fission fuel on the table. Carbon capture and storage on the other hand is a complete joke if you take even a cursory look at the numbers (and volume) involved.

If it's already in unstable, 99% of the work is done and the best option is probably a simple backport.

That's only because the binary was built against that version, a problem which will go away by itself if you recompile it as above.

Yeah, nah. Why?
First you need a mouse and a GUI, both of which make it a non-starter for serial console or SSH on headless machines. Then you've got the not-uncommon gpu-driver/KMS shenanigans, and on top of that you're dependent on a particular tool on a particular live disc that you will sooner or later not have handy.

That's without even starting on all the fun to be had with "automatic" repair tools if the system has an unusual bootloader, custom boot configuration or chainloading, RAID, root-on-ZFS, netboot, the list of things such tools will probably either not handle properly or completely louse up goes on.

OTOH, pretty much every bootable GNU/Linux media in existence has mount and chroot, and once you're in that way you have all the tools and existing configuration of the installed OS right there.
You also have the opportunity to fix the problem properly the first time and verify that the installed tools (i.e. update-grub, update-initramfs, dpkg configuration etc.) can reliably update the bootloader for next time.

Why reinvent a perfectly good (and not particularly oft-used) wheel just to make your mouse pointer feel useful?

Or you could just chroot in and do 'dpkg-reconfigure grub-[insert platform]', which is pretty much how d-i installs the bootloader anyways and should suffice for most scenarios.
Personally I have no use whatsoever for refractainstaller, but if I were a betting man I'd say that's what it calls for the bootloader step too.

That's not a bug, it's a design decision.
X was not developed for personal computers, it's fundamentally a graphical mainframe technology. In that scenario the trust model is inverted WRT a PC - i.e. the network is secure, applications are served from the mainframe and implicitly trusted, the terminal running the xserver is not.

X is as secure as it has ever been and (at least for now) it's still getting patches for any newly discovered issues, but the core design concepts don't transfer particularly well to the age of software-as-an-enemy... Then again, as long as you don't run untrusted applications that might want to screenscrape or keylog you, you're fine.