Appreciate your thoughts. Yes, I can upgrade to the new procps and accept the different  memory reporting and hope it'll be corrected soon. I can also keep the older procps until the problem's resolved, hopefully soon. I've had to put a hold on a pkg several times when the upgrade was available but one or two of its dependencies were not. I'll keep the older procps for now until some other essential pkg/s require the upgrade.

FWIW
The new procps has libprocps as a dependency. I didn't find any reported bugs for the library but I did find the links below for procps-2:4.0.2-1 and a fix for 2:4.0.2-2. Neither mentions a memory reporting problem. Despite what was fixed, procps-2:4.0.2-2 caused the memory problem. There might be more bug reports but I didn't find any.

Oct 24 2022
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022573
Dec 5 2022
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025495

A search in /.local/shared/xorg and /var/log showed no 'download' in the current or old files, in either of the sda or sdb OSs. My understanding is the log shows loading/testing/unloading until the correct mix of modules for your hardware is found... screen, mouse, keyboard, etc. When my 24" screen died (DVI to HDMI) and I started using the 37" TV (HDMI to HDMI), no adjustment/tinkering was needed... it just worked. Assuming the download is from some online source, it seems odd and worth checking.

memory is back to normal

The memory usage is the same irregardless of the tool used to measure it. Just accept the new procps package, it does not increase your RAM usage, it just reports it differently.

And sorry for missing that — I did check the procps changelog but obviously not carefully enough.

Maybe this is the cause of the discrepancy?  apt-listchanges news:

procps (2:4.0.2-1) unstable; urgency=medium

Downgraded to 2:3.3.17-5+devuan1, rebooted and memory is back to normal.

Damn fine catch, rbit. Thank you!

Procps was updated on Dec 6:
[UPGRADE] procps:amd64 2:3.3.17-7.1devuan1 -> 2:4.0.2-1devuan1

Maybe this is the cause of the discrepancy?  apt-listchanges news:

procps (2:4.0.2-1) unstable; urgency=medium

  * free: Used memory is Total - Available
    This means versions of free after 4.0.0 will show different Used
    values for older frees and some other system utilities.

 -- Craig Small Mon, 05 Dec 2022 21:34:57 +1100

Yes, it is. The ps -C Xorg -o user cmd from your link shows X running under USER/me, so the log shows up in my home dir.

@aluma

Please explain 'it downloads' and/or what to look for.

Anyway I don't want to drag this thread off-topic so I've posted how to get EXE to run X under the normal user in the screenshots thread:

https://dev1galaxy.org/viewtopic.php?pid=39482#p39482

The advice also applies to Devuan so perhaps it will be useful for the OP even though it's off-topic here.

Tell EXE to stop running X under the root user then, it's really bad for security...

It's you yourself.
I have a different opinion on this matter.

I have a GNU/LINUX EXE installed with default system settings. The Xorg.0.log file is exactly where I indicated

Tell EXE to stop running X under the root user then, it's really bad for security. Debian moved away from root-owned X seven years ago[1] so the derivatives should really catch up. IMO.

aluma wrote:

/var/log/Xorg.0.log

That location is only used if X is running under root. I think the OP's log will be under ~/.local/share/xorg/ but their use of custom startup scripts complicates the picture somewhat.

I won't argue, I have a GNU/LINUX EXE installed with default system settings. The Xorg.0.log file is exactly where I indicated (in general, in other distributions too, but I never installed X as a user).

sync; echo 1 > /proc/sys/vm/drop_caches
sync; echo 2 > /proc/sys/vm/drop_caches

The kernel is quite capable of dropping the cache by itself if the memory is needed. And anyway the free output clearly shows that the buffers are almost empty. See also https://www.linuxatemyram.com/.

That location is only used if X is running under root. I think the OP's log will be under ~/.local/share/xorg/ but their use of custom startup scripts complicates the picture somewhat.