It's not mine, it's just some random script I stole 'cause I'm too lazy to write an evdev test in a more sane language, and it's simple enough for even non snake-charmers to see it's not a bomb
Readline is set to produce an audible bell? (/etc/inputrc and ~/.inputrc)?

Uhh, why would you even contemplate that without backing up the system first?
... Thanks for being a proverbial canary though, I guess. I stand by my "good and ready" statement above.

Pretty much every bit of the highly visible "progress" WRT "desktop" GNU/Linux (and OSS/FOSS in general) these days is to please:
a: RedHat IBM
b: IBM's customers
c: Commercial software vendors
d: Users who care more about running commercial software than software freedom

Hence the ongoing campaign to standardise enshitify or replace core components (under weak licences of course), reduce distro fragmentation diversity, agressively break compatibility with deprecated perfectly servicable but agenda-inconvenient software and systems, simplify packaging of closed-source software spyware and other garbage, and hide the system behind inscrutable abstraction layers and "user friendly" UIs so windows refugees feel more comfortable IBM can sell more support contracts.

On gentoo ( not that that makes much difference):

$ git clone --recurse-submodules https://github.com/transmission/transmission Transmission
---snip---
$ cd Transmission
$ cmake -B build -DCMAKE_BUILD_TYPE=Release
---snip---
$ cd build
$ time cmake --build . -- -j 20
--snip---
[ 88%] Built target transmission-gtk
---snip---
[100%] Built target transmission-qt

real    1m10.308s
user    18m8.638s
sys     0m48.282s

5 commands, less than 2 minutes, no additional packages required, and no issues whatsoever to report.

Transmission is a perfectly ordinary cmake project, and building it is exactly as easy as it might seem... Provided, as the OP has discovered, you actually have the complete source tree to begin with.

If I was motivated enough (and had a debian/devuan desktop handy) I could likely build a Debian package almost as easily, but I'm still waiting to hear what's so great about this shiny new version.
3.x works just fine for my (headless server + webui) needs, and I see no reason to disturb a working system for the sake of "newer always better".

OTOH, if we keep up the "I don't know the answer, so just use appimage" and "download from official website" (AKA "I have 'ex-windows user' tattooed on my forehead") type nonsense, this place can be as devoid of useful technical information as FDN in no time.

Why would there be a log file, when the cmake output already makes the problem blindingly obvious?

-- Could NOT find DHT (missing: DHT_LIBRARY DHT_INCLUDE_DIR) 
CMake Error at /usr/share/cmake-3.25/Modules/ExternalProject.cmake:3115 (message):
  No download info given for 'dht' and its source directory:

   /home/jemadux/projects/source/transmission-4.0.5/third-party/dht

  is not an existing non-empty directory.

Have you looked at the directory structure mentioned? Does it contain sources for the DHT library?

Presumably you are trying to compile from the release tarball... Which for reasons unknown does not appear to include any of the required third-party sources.
Those you will likely need to retrieve via git, either manually or by cloning the project with --recurse-submodules as per the "Building Transmission from Git" instructions.

Or, as already suggested, you could simply forgo the SNS and use a stable, tested release from the repositories. What "must have" feature does 4.0.5 include anyway?

At a guess (haven't used XFCE in a while), thunar uses GVFS/FUSE user mounts for FTP or copies the file to a temporary directory, so there's a real filesystem path MPV understands. Dolphin (and the rest of KDE) uses KIO for transparent FTP, which only works with applications that understand KIO URIs.
With so little detail provided, a guess is the best you're likely to get.

The bigger question might be why you're using FTP to stream from a local server to begin with, when things like NFS and SMB (or even SSHFS) exist... Or if you must use FTP, why it's not set up as an FTPFS mount. curlftpfs removed as of bookworm, reasons unknown
FTP is designed for contiguous file transfers over the internet (or dialup BBS), not the kind of random-access one expects directly accessing files (i.e. NAS-style) on a local fileserver.

Video Acceleration API is... A video acceleration API. It shouldn't have anything to do with sound. Nor should mesa... Unless of course there's something totally broken regards the fallback to unaccelerated decoding, but I doubt it. Firefox error messages kinda suck though.

The Cubeb / OnMediaSinkAudioError lines are likely the relevant ones, I suggent a general websearch on those for a start. I don't have Debian / Devuan on any desktops right now to investigate myself.

What more does running with MOZ_LOG=cubeb:5 (or a log level of your choosing) have to say?
Do you have any custom ALSA configuration (.asoundrc, /etc/asound.conf)?

If it hadn't, https-everywhere would have killed it anyway. You can't really have local proxies and SSL at the same time, at least not how modern browsers are designed and modern users are trained.
All it takes is for someone to notice that faceborg is suddenly signed by proxomitron instead of DigiCert Inc, and the "muh securitee" wailing starts. Users are of course properly groomed to run arond with their hair on fire if they see any kind of browser "security warning", rather than reading details and making informed decisions.

All this is really just the same old war. Commercial entities want total control over how their sites (and apps, in the mobile space) display and how you interact with them, and that means locking down browser endpoints and preventing tampering with DNS and network traffic.

Pervasive use of obfuscated javascript where HTML would do.
Ever-expanding list of web "standards" and extensions that make it near-impossible for independent browsers to stay compatible.
HTTPS everywhere (even when no sensitive data is being exchanged).
DOH, and the "your ISP could spy on you, better trust google or cloudflare instead" non-argument.
Manifest v3 and the wider attack on content filters.
WEI (shot down for now, but it'll be back).
"SafetyNet" and other mobile OS attestation systems (which will come to PCs in time, we have "anti-cheat" rootkits and the like already).

All of this is touted as being for your security... It's not, it's for theirs. Google is of course the arch-villain here, because nobody wants to control what you see so much as a corporation funded by and founded on advertising.

IMO the only real solution is wholesale rejection of the current "web v2 (and supposed v3)" and it's centralisation of power. It's corrupt beyond recovery at this point, and is only getting worse.
I'd love to see the likes of gnunet, gemini, and other decentralised solutions gain popularity, but so long as all the frogs want is online shopping and social media, we're kinda screwed. If the water only gets a little bit warmer with each new "improvement" it's fine, right?

Squid doesn't have anything to do with DNS, it's a caching/filtering HTTP proxy. Such proxies aren't seen much anymore, because they don't really work on encrypted (i.e. HTTPS) connections.
Anything that does caching/inspection/filtering of HTTPS traffic needs to decrypt it, and that means installing a root cert on the client, which pretty much breaks the SSL trust model... Not that it stops corporate networks from doing exactly that, for "safety".

The browser has the SSL keys so it can do all this. That's kinda how most decent ad/content blockers work already, once you go beyond host lists and into selective element blocking (that's also part of why manifest v3 is bad, as it hobbles this ability to modify content before it is displayed or executed).

DNS is another matter altogether, and there's nothing stopping you running your own resolver (e.g. BIND) on your own network, with your own rules. Screwing around with cache expiry/TTL and locally resolved "whitelists" will likely just land you in a world of "my DNS is broken" hurt though.

Benchmarks or it didn't happen.

Okay then, why (technical explanation, not pseudo-jargon and hand-waving)... Also, benchmarks or it didn't happen.

That's an extremely normal memory consumption for a fresh-boot minimal XFCE desktop.

Unless your system has some weird caching limitation (which AFAIK hasn't been a thing since L2 moved on-die in ~1999), you have severe memory fragmentation, or you are running into memory pressure, how much RAM the desktop uses is of no relevance to system latency.
Again, benchmarks please.

Sigh. Benchmarks or it didn't happen.
"Everything will be twice as fast" is an extraordinary claim, and extraordinary claims require extraordinary evidence.

Subjective performance. Where benchmarks?

Either you have found a bug (in which case you should report it, with all relevant technical information and logs), or this is just more hand-wavy pseudo-technical "explanations" for "I broke it because I don't know what I'm doing", like the last post... Guess which one I'm betting on.

...
Or perhaps it's asking to much for someone with "extensive experience, having tested and worked with basically 80% of all the linux distros" to exercise any scientific rigour whatsoever when doing performance tuning and writing "guides"?

Well it is Motörhead, I mean that's kinda the point.

https://www.youtube.com/watch?v=Wh3t49NsWBA