Dear boughtonp you are a hero.
I tried all versions against each other....
(by 100% scientific loud counting :-) )
--- cryptdisks-functions.orig   2023-01-31 21:00:09.967829315 +0100
+++ cryptdisks-functions        2023-02-11 20:17:49.665380782 +0100
@@ -186,6 +186,7 @@
do_stop() {
     local devno_rootfs devno_usr
     dmsetup mknodes
+    [ -x /sbin/lvm ] && /sbin/lvm vgchange -a n >/dev/null 2>&1
     log_action_begin_msg "Stopping $INITSTATE crypto disks"

     devno_rootfs="$(get_mnt_devno /)" || devno_rootfs=""

This version took the same ~ 6 seconds to shut down my desktop as the version looping over the vgs.
The lvm manual was right. :-)
I also counted the time for the original version and that was ~ 40 seconds to shutdown.
Thank you!

Dear boughtonp all your code suggestions look cool.
What makes me like (even realy ugly looking) sed code one liners over awk or shell loops is resource considerations.
This code is run once at shutdown. To me it is unlikely that parts of the code are somewhere cached in the CPU caches.
sed has an extremely small footprint (in memory and CPU usage).
This patch adds to 99% of all systems an additional slowdown of less than a 1ms during shutdown due to the check for lvm

 if [ -x /sbin/lvm ];

which I think is a fair deal, because 100% of all systems running lvm on top of LUKS will benefit from that with additional 120 seconds less waiting for a shutdown.
Because cryptsetup does check for open VGs living on LUKS devices and does oppose to a possible premature closing of those devices with the VGs still online.
(I like that kind of error caching.)
Usually I run my laptops with at least two different VGs each holding different PVs.
If you come up with a solution which is small, easy to read and faster than the one I wrote - may rolfie decide ....

The the AMD graphics firmware is installed and AMD Graphics works from the very start beautifully.
I guess I have to give GRUB_CMDLINE_LINUX in /etc/default/grub a closer look and have check for pm scripts to remove and reinsert kernel modules.
My problem is that my wife is using that particular notebook very productive in school now - and I have to wait for a timeslot to tackle that issue. 
I'll report any news here.

Imho you can share /usr - in ro mode - if you never ever come to the point and do updates. apt can't handle this. If you are creative and like playing - you can try overlay file systems to overcome that to a certain point where complexity breaks you neck.
In non systemd systems it is practically possible to share [ro]  /usr between identical machines, which are painstakingly kept synchronized concerning their package configuration. (We used to run SunOS servers ("clusters")  this way in another century.)
Just do it - and see what happens!
For the systems with the [ro] /usr - you will need to find a way to fool apt. (snapshot && overlay && throw away -> actual updated /usr from mount - would be my first guess - but maybe there is a simpler solution? Maybe you can do it all with translucent logical volume caches?)

A quick reply to this thread.
To me stability, and low administrative workload generation is a target I pursue with every laptop I configure for my clients (family mostly). Also privacy and usability are important to me.
The last 30 years I learned that the operating system should ripe and age with the hardware in use - to keep administration effort on the lowest possible level.
I recently got a Tuxedo "Aura 15"  (a Clevo OEM)  with AMD Ryzen 4700U and thus RENOIR graphic integrated.
As there is no (at least I didn't find it) ISO for chimera I booted a beowulf 3.1 iso and installed a fde chimera on it.
I painstakingly installed all the necessary firmware packages and the graphics just worked out of the box.
Ok chimera is testing ... (but a lot better the the preinstalled Ubuntu Frankendebian).
I only found that the KDE akonadi was even more crap than expected ('apt-mark hold "akonadi* packages"' helps to keep that uninstalled stuff out)- but I guess the overall workload to keep that laptop patched and functional the next 5 years is significantly lower than starting with (a heavily patched MX-Franken-)beowulf - and because of that reinstalling a chimera once it is officially released.
Your mileage may vary.
I just want to point out installing minimal beowulf and migrating it to chimera is an option for that brand new hardware.

@fsmithred

Thank you! Works like a charm. I'll include that in my tutorial on full disk encrypted devuan.

Dear kapqa - this topic seems to me less distribution specific but SAMBA version specific. @work I run several SAMBA installations with several Windows fileshares - and every 2-4 years SAMBA or Microsoft or both break the working configurations. So a smb.conf on a linux running SAMBA 4.6 with for an M$-file server running on Windows 2003 fails with SAMBA 4.7. Fixed that -a  few month later the concept is broken with Windoz2012 replacing Windows 2003....
I don't want to blame SAMBA - they do a horrific job for me and M$- but they have to shot on a moving target - and backward configuration compatibility - as well as a configuration beauty contest isn't top one on their list.
As I don't have your environment here I cannot diagnose your problem - but maybe I can give you some hints.
1) You really don't care for security and need a quick and dirty fix - here you are:
Get the source of the last version which worked - spend an weekend in getting the necessary environment to get it compiled - install and enjoy.
2) If you like hacking - and like to learn more from your system setup SAMBA is a good starting point. (Good character building stuff!)
- Try to get your MAC Server to go to debug mode (RTFM)
- Read and try several documented and less documented modes and parameters in the samba client.
- Google for the error messages.
- Reconfigure smb.conf on both sides (and restart services)
- Succeed or fail. - Even if you fail you have learned a lot.

Additionally pulseaudio wants ofono to be installed.
When having it installed you get something like:

in /var/syslog.
To get this to work edit
/etc/dbus-1/system.d/ofono.conf

and add
...
  <policy group="bluetooth">
    <allow send_destination="org.ofono"/>
  </policy>
...
below
<policy user="root">
...
  </policy>

Make sure the users of the desktop are members of the group "bluetooth".

Thank you - but to my experience - “using a initramfs hook after root device has been unmounted” is not necessary.
It is completely sufficient to vary off the volume groups with vgchange - as demonstrated in my patch. (My computers (with root on encrypted lvm) running with that patch - shut down immediately, when I click on shutdown...)
The only concerns that might arise with that patch - are possible compatibility problems for high availability frame works. But to my experience those are usually that generic - that you have to “tattoo” the hardware environment into their surrounding scripts anyway. So this additional “feature” of safely shutting down all  volume groups - might be in there in another way already - and would be redundant with this patch in place...

I had the same problem with DEVUAN ASCII.
I filed a bug and a patch - but nobody was/felt responsible....
https://bugs.devuan.org/db/23/237.html

For beowulf I had to change it slightly - I didn't file it yet. Here is the part
from my ascii patch which basically needs other line numbers is beowulf.
(The obvious problem is still there - unpatched.)
If you look for the file "cryptdisks.functions" and change the function "do_stop()" accordingly the problem is solved.
In beowulf I also adjusted the local variables to only "vgs" and "vg" as far as I remember.
I plan to file the next day a patch for beowulf.
Maybe this time - this quality issue can be resolved.

------------------------patch------------------------------------------------------
--- /lib/cryptsetup/cryptdisks.functions.orig   2018-08-14 17:12:31.543227705 +0200
+++ /lib/cryptsetup/cryptdisks.functions        2018-08-23 16:36:23.849064962 +0200
@@ -763,9 +763,17 @@
 
 # Removes all mappings in crypttab
 do_stop () {
-       local dst src key opts opencount major minor
+       local dst src key opts opencount major minor vgs vg
 
        dmsetup mknodes
+       if [ -x /sbin/lvm ]; then
+        vgs="$(/sbin/lvm vgscan | sed -n '/"/s/^.*"\([^'\'']*\)".*$/\1/p')"
+         if [ -n "${vgs}" ]; then
+          for vg in ${vgs}; do
+           /sbin/lvm vgchange -a n ${vg} >/dev/null 2>&1 
+          done 
+         fi
+        fi
        log_action_begin_msg "Stopping $INITSTATE crypto disks"
 
        egrep -v "^[[:space:]]*(#|$)" "$TABFILE" | while read dst src key opts; do
------------------------patch/-----------------------------------------------------

.

The above patch silently varys off the VGs and makes handle_crypttab_line_stop work

So shame on the cryptsetup admins of debian and devuan.
They never tested the system with a encrypted root partition.