Error: eval: unbound variable: (/usr/share/gimp/3.0/scripts/text-circle.scm : 17)  symbol-bound?

Likely has nothing to do with GIMP not starting, it's an error in a "legacy" script from gimp-data-extras. That package is kinda where unmaintained scripts and plugins go to die, so unless you need that specific script it should be safe to ignore.

Native wayland support in GIMP is pretty new, and I have no idea how well (or at all) it works on Debian/Devuan. I can fairly confidently say it's not a problem with GIMP itself (i.e. works fine on wayland/Gentoo and has since 3.0), but that's not to say the Debian build isn't broken somehow.

Why? GIMP starts fine with XWayland, does it not?

As usual, bashing $favourite_punching_bag and reposting the same old page for the 1000th time without even attempting to address the problem at hand does nothing to solve the problem at hand.
Surprised? Not.

If you have malware running then it already has access to everything in your home directory, including browser storage and login cookies. Keyloggers are the least of your problems. The wayland cultists love to wave this one around since "keylogger" is nice and scary, but really the solution is to simply not run malware, same as it has always been.
Wayland "application isolation" is nice-to-have, but it's not a panacea and it won't save you from any attack currently in the wild.

Something needs direct access to the graphics and I/O hardware, whether that's the xserver or your compositor (and which of those is "less code") is a matter of taste.
Running the whole xserver as root hasn't been a thing in most distros for a while now (at least not those that use a session-broker/seat-manager), these days it gets access to only the devices it needs - just like a wayland compositor does.

But not "crawl into the footwell and connect the wiring for the radio", which is a far more appropriate analogy for what new users are expected to do to get pipewire working properly.

Every other distro (systemd or otherwise) which ships pipewire also ships an OOB configuration where it just works. No "tinkering", no reading manuals, no scouring forums or writing shell scripts.
Tinkering is fine if you want to customise your install or do something unusual. Pipewire is not unusual. It hasn't been unusual for several years at this point, and literally every other distro has accepted that it's not going away and solutions need to be found to integrate it.
Devuan has, what, grudgingly added a paragraph to the release notes instructing users to go figure it out? Rejected every proposed solution because it's not in upstream Debian? Chased away anybody who would be willing to work on this?

The irony is palpable. Whinging about not enough developers, then running off anyone who looks like they might contribute. Bitching about upstreams not listening to their users, then refusing to include functionality users are asking for. Blaming Debian for any and all bugs and behaving like they're part of some big evil conspiracy, then claiming that "Devuan is just Debian" and stonewalling any remotely proactive discussion with "we'll wait and see what Debian does" or "get package into Debian first".

Devuan is little more than a shallow Debian "respin" at this point. 99% of packages are pulled straight from Debian, even when that means they're broken or grossly misconfigured by default in a systemd-free environment. Nobody, apparently, cares at all.
Obvious low-hanging-fruit like shipping a simple shell script or running sed against a configuration file go unpicked, and users are left to figure these things out for themselves. Trivial 5-minute bugs go completely unanswered for years on end.
Even the live image, that one configuration among the multitude that should be tested and polished as the flagship and first-impression... is almost always broken on release day.

Perhaps it's time to stop calling this a "Distribution" altogether? Every other systemd-free distro appears to be making progress with systemd alternatives and ensuring packages work and OOTB configurations are functional, Devuan just reheats whatever Debian serves and buries it's proverbial head in the sand.

Why? The distro is going nowhere and the discussion channels are administered by arseholes who won't even walk their own passive-aggressive talk. What would be the point?

If you're going to ask a brand-new user, one who came here asking for technical help, to "provide and maintain" a solution, maybe start by showing your solution as inspiration? An example of all the packages you maintain perhaps? No?

You suppose correctly.

It's Debian without systemd, with a perpetual list of bugs caused by removing systemd and a pathologically passive attitude to fixing any of them.

... Is the understatement of the decade when it comes to our dear forum administrator here.

That's because it (still! ) doesn't.

See the release notes and the relevant thread argument.

May or may not work, subject to the phase of the moon (service startup is order dependent and 'foo &' doesn't wait). See better solutions further down the aforementioned argument.

Devuan's stubborn refusal to implement any of the multiple user-service solutions already suggested, or package even a token-effort shell script.

'gparted' appears (at least on Gentoo, I have no GUI Devuan installs) to be a shell script which ends up calling pkexec --disable-internal-agent '/usr/bin/gparted' if pkexec is available.
See if that command works in a terminal emulator as your normal (non root) user, and what output it produces.

Only after people with more clues provided the solutions. Zero credit due golinux on that one.

TLDR: If you don't care about .xsession-errors, bind-mount it to /dev/null. If you want to keep it (but still don't like huge files), set up logrotate with compression - even gzip will achieve near-magical compression ratios on a log file containing mostly repetitive messages.
If you want the underlying bug fixed, report it to the upstream for whatever GUI junk is flooding stderr.

The other elephant in the room is firmware behaviour.
Consumer SSDs have a minimum erase-block size and can suffer from free-space fragmentation issues. They usually don't have uniform write performance in general, relying on cache/host memory and a dedicated "fast" area to buffer writes until they can do a more efficient block allocation.

The upshot of all that is that SSDs do quite a lot of sneaky things in the background to appear faster than the flash memory actually is, they need regular "trimming" to release blocks and power-on-idle downtime so the firmware can do garbage collection, wear-leveling, and free-space defragmentation.
If any of that goes sideways (IME usually due to firmware bugs), performance will fall off a proverbial cliff.
Check both drives are running the same firmware revision (and update if any are available), check the wear-leveling counters in SMART, and try a full zero-fill wipe followed by a trim on the problematic drive.

Benchmarks or GTFO.

How strange they're still being manufactured in volume, and the technology (e.g. HAMR) is still under active development.

You were forced to think for yourself. Devuan can run any root filesystem supported by the kernel (as can most distros), the limitation is only in the installer. As for /home... That's utterly trivial to set up after install, with any filesystem you like.

i.e. more paranoia BS, from someone with likely little idea what it actually does or what attacks it might defend against, since they apparently need "step by step" instructions to write a trivial init script.

Next will be out-of-repo "privacy" browsers, VPNs, and whatever go-fast shiny-new-shit is popular on Arch/Artix right now.

"Toxic" OP, complete with entitlement, shouting, and misguided assertions that your personal preference regarding DNS should be a distro-wide default.

I'm not laughing at DoT, I'm laughing at people who consider it not being enabled by default and integrated into some random GUI a "complete showstopper".
Devuan, like Debian, comes with a standard DNS configuration by default. If you want something else, it's on you to read the documentation and set it up.
Likewise init systems - sysv is the default and best supported. If you want something else, all the parts are available but you get to assemble them.

Or just use separate AP(s) for your untrusted/guest network, and put them on an isolated VLAN... Like sensible people have been doing for about as long as wifi has been a thing - because wifi has been subject to a variety of security issues since day one, and untrusted devices or networks cannot, by definition, be trusted.

Assuming you are talking about this stubby, now I'm wondering if you even understand the article you linked... What does a DNS stub-resolver have to do with anything, and how is it supposed to be a "defence" against a layer-2 port-spoofing attack?

Breaking news: It happened some time ago, and the majority of distributions and desktop environments are using it.
Personally I don't think wayland is ready to replace X, but many seem to like it and that's a perfectly valid choice.

As for the OP: Sandybridge with 8GB of RAM will run pretty much any current distro acceptably well. The biggest problem will be, as always, the demands of a modern standards-compliant web browser.
If it only has 4GB installed, look into upgrading it. Most machines of that generation can take at least 8GB, usually up to 16. AI insanity notwithstanding, used DDR3 DIMMs are dirt cheap.

ARM binaries simply will not work on an AMD64 architecture, trying them is pointless.
The driver linked in post #5 is the correct architecture and already in the correct format (so no mucking around with xarchiver or alien required), just install with apt or dpkg, e.g.:

apt install ./epson-inkjet-printer-escpr_1.8.7-1_amd64.deb

Whether it works is another question, I don't have applicable hardware.

Are you sure that's not just Epson's website setting x-content-type incorrectly, causing your browser to render the binary file as text rather than downloading it?
Try wget or curl on the URI you get, e.g.:

wget https://download-center.epson.com/f/module/e81c57ab-d783-435d-bd64-e74bac7c72b4/epson-inkjet-printer-escpr_1.8.7-1_amd64.deb