I would *assume* that a merged /usr would have moved everything in /sbin to /usr/sbin and replaced /sbin with a symlink to /usr/sbin (and similar for /bin, /lib, etc). But that's probably too simple for the designers to think of.

Is there a /install/gtk/initrd.gz in your / or /boot ? If there's a /initrd.img on your system is it a symlink to somewhere?

I'm not an expert, but I know that the system loads an initrd.img early in boot processing (possibly compressed). So I'd expect that entry to point to the one the system should use. So removing that entry might stop your system booting.

Does your /etc/default/grub say anything like:

# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

If so try that.

Post that to the github discussion. It might point then towards the bug. (Sorry if you'e already done that).

Is there a /boot directory? I assume you are running as root so will be able to write to /boot

That's all I can think of, but sometimes checking silly things can find silly problems.

What happens if you tell it to use googlemail.com instead of gmail.com ? I have one system using kmail where it insists on using the wrong type of auth for gmail.com but I can get it to work with googlemail.com (it's kmail being "clever" that causes the problem). I can't check details on that system just now though, sorry.

That took quite a lot of puzzling to work out.

From man locate
locate reads one or more databases prepared by updatedb(8) and writes file names matching at least one of the PATTERNs to standard output, one per line.

So if updatedb ran when the filesystem was not mounted it would find the "hidden" files and put them into the database. So running locate repeatedly would always show them, until the next updatedb run.

Read the man page for env.

#!/usr/bin/env python3

Will only work if python3 is in it's $PATH. Try which python3 to make sure it's installed on your system.

First try running memtest86 for a few hours. Run it single threaded first. If it doesn't hang or report any faults try it again multi threaded. If memtest86 crashes as well then the OS must be innocent.

Next boot Linux and run watch sensors in a terminal window. That will show how hot the CPU etc are. If it gets over 100C then check all fans are OK, there's no fluff on the CPU, etc.

I've just found (from an article in Linux Magazine) that there's a program called adequate which sanity checks packages for violations of Debian package guidelines.

Install with apt-get install adequate and read it's man page for details (it won't usually need to be run as root). From a quick check it should find various packaging errors, although there can be false positives. And it only checks if a package is correctly packaged, not if it actually does what it is supposed to. But it looks worth adding to recommended workflow.

Does the path to the directory have spaces in it? That could confuse things.

Try:
ls -A  /media/charon/seagate backup plus drive/dr web
If that gets similar errors try:
ls -A '/media/charon/seagate backup plus drive/dr web'
Putting quotes round the path should stop spaces in the name causing problems.

Assuming the directory really is empty (ls -A should return nothing if it is empty) try:
rmdir '/media/charon/seagate backup plus drive/dr web'

And similar for renaming directories.

When you see an example command starting with a $ don't enter the $, just the rest of the command. It's usually the terminal prompt.

In the unlikely event you did need to enter the $ the poster would tell you explicitly.

How much memory does the system have? It might well be that systemd uses a LOT more memory, so the system starts page thrashing.

Either way it's nice to have another objective argument against systemd.