udiskie -s --automount --notify &

^ This. GVFS should be taking care of automounting. Use the relevant options in thunar to configure it.

I could bring up a lot of other potential issues in that file but they would all be off topic here so I will restrict myself to observing that ~/.xsessionrc is read by /bin/sh so bash -c is redundant and also that & should only be appended to a command if it doesn't return the prompt when run from a terminal — unnecessary fork()ing can cause race conditions and strange problems. And it's best to use update-rc.d or sysv-rc-conf to enable services rather than starting them manually. And don't use xrandr to set brightness, that's just a software alteration and reduces the available colour range. And [snip]

I think gvfs does not like sysV

So then why does it work under sysvinit in both my installed system (see earlier screenshot for proof of this) and also in the chimaera live ISO? Try the live image for yourself and report back.

trash:/// is actually located at $Home/.local/share/Trash.

Whether or not I have 'functioning' trash, the folder exists on both (Devuan and MX). It only functions on systemd MX.

Later that same day in a city 'not far away'... I decided to try and see what happens with antiX21 (runit). It works just fine.  Trash functions exactly as it should. Aside from my lack of skills and manually dexterity, I am left thinking the problem has to do with sysV init.  I think gvfs does not like sysV.

I am left wondering.... "How many angels,ARE able to stand on the head of a pin?"

functioning trash

^ What does this mean? You will have to explain it to me in as much detail as possible because I don't use graphical file managers so I have no idea how "trash" is supposed to work.

When I load up devuan_chimaera_4.0.0_amd64_desktop-live.iso in a VM I can navigate to the "Trash" [sic] side pane shortcut (identified as trash:/// in the location bar) and if I highlight a file elsewhere and press the <Delete> key the file appears in the trash:/// location so it seems to work but perhaps I am misunderstanding.

Interestingly when I use MX it does not have functioning trash (when booted usingsysv-init); identical with Devuan.  However, MX when booted with systemd has normally functioning Trash.  Debian also works just fine in it's systemd incarnation.

In all cases, the trash folder remains existent in my .local/share folder. On MX, a boot/ reboot between systemd- sysvinit on the same machine (minutes apart) has the trash folder appear/ disappear. FWIW. I, also, either loose or have the delete/trash maintenance options appear/disappear in accordance with the Trash folder.  (Exists in systemd booted envirnment, not in the non-systemd incarnation.)

I tried the following file managers with the exact same results:
PCmanFM, nemo, nautilus...

It all makes me happier when using systemd.....

So how did you install ceres then?

And what do you mean by "I lose Trash on Thunar", exactly? What behaviour do you expect to see and in what way does the observed behaviour differ?

You can use this to check what has been installed from that Skype repository:

aptitude search '?narrow(?installed, ?origin(. stable))'

^ That should just show skypeforlinux. Hopefully. I would just use chromium for Skype, or even the flatpak, but you might be comfortable handing over the keys to your system to the repository maintainers.

Scrot or it didn't happen:

So now the question is: how exactly did you install your "daedalus/ceres" system? I used the chimaera netinstall ISO image.

Use this command to show us exactly which version is installed (which you should have done in the OP btw):

apt policy

Looks like this is a PEBKAC issue

You could try recompiling the source package with --disable-systemd:

apt source gvfs && cd "$_"-*

Then edit debian/rules and change this section:

ifneq (,$(filter $(DEB_HOST_ARCH), hurd-i386 kfreebsd-i386 kfreebsd-amd64))
        ADMIN_BACKEND=-Dadmin=false
        SYSTEMD_FLAGS= \
                -Dsystemduserunitdir=no \
                -Dtmpfilesdir=no \
                -Dlogind=false \
                -Dgudev=false \
                -Dudisks2=false \
                -Dcdda=false \
                -Dgphoto2=false \
                -Dmtp=false

To this:

ifneq (,$(filter $(DEB_HOST_ARCH), hurd-i386 kfreebsd-i386 kfreebsd-amd64))
        ADMIN_BACKEND=-Dadmin=false
        SYSTEMD_FLAGS= \
                -Ddisable-systemd

Then run

# apt install devscripts
# mk-build-deps --install --remove
$ rm gvfs-build-deps*
$ dch --bpo # open debian/changelog in an editor, save the file to exit
$ debuild -us -uc
# apt install ../gvfs*.deb
# apt purge --autoremove gvfs-build-deps devscripts

Careful with that --autoremove option though, it might take out your desktop if you've uninstalled any critical metapackages. Pay close attention to the output. Or leave devscripts installed if you want to keep it for any future rebuilds or package patching.

Anyway, if that gets the Trash working edit debian/changelog to change

gvfs (1.46.2-1~bpo11+1) bullseye-backports; urgency=medium

to

gvfs (1.46.2-1.1) bullseye-backports; urgency=medium

Then rebuild the packages again and install them. You'll have to repeat this whenever the GVFS packages are updated.

If it doesn't work then reinstall the stock packages:

# apt update
# apt full-upgrade