I try to avoid running Tomcat natively even if I can.
For me, it is much better to use a Docker image with Tomcat, eventually modify it, and then run the applications there. Tomcat running natively is subject to all sorts of interferences, version conflicts etc, in principle the runtime behavior may be affected by even small system modifications. And, at least over some years of use, problems are likely to occur. As long as you can build the packages to run (in a pinch, you can setup a Java container for that), there is  very little fuzz running Tomcat that way.
It is also a safe way to work if you, like me, build packages to be deployed at production servers running Docker. (Or Podman, or...)

Thanks for the replies! :-)

That's very good for general, especially more occasional, use, but in my particular use cases, it hasn't been so useful. I have ended up doing (lots of) manual mounts for necessary control, for example. I think it has something to do with the 'need to be open'-thing too. Most volumes are unmounted most of the time etc.

Good to hear! My intuition is that I should rather make the mounting/unmounting more efficient than rely on gvfs automation.   And for me, the default is for services to be turned off when not in use: Boot partition/bootloader/initrd&kernel unmounted, init scripts rested when they have done their thing, media offline when not in use etc. Some of it, I think may be general good practice. The rest mostly related to workflow and reducing the impacts of own user errors.

Maybe one could just add a line to the default /etc/rc.local in the first place?

[ -d /etc/inittab.d ] || mkdir /etc/inittab.d

I use this mechanism for other 'non-default' directories that are useful or necessary for me.

Who talked about trusting AI?
I don't really trust any of the equipment I use. It's essential for me nonetheless.

Another small update, probably the last one on this case:
Debian 12.12.0 works out of the box with persistence under kvm. So the change has happened somewhere between 11.2 and 12.12.
As for using kvm to set up a new version, I just 'copied' a Devuan install with broken packages by taking the diff on packages lists, cutting the resulting list (ca 960 packages) in 5 smaller lists and using xargs to provide apt with the package names from the lists. That worked, in kvm with 3 GB memory. Apt didn't fix it when all were provided at once.

Maybe that group of people is not of a fixed, pre-determined size?
Speaking for myself, I tried the first Devuan releases, had to give it up because too much of what I needed didn't work well enough for me then.
Now, I am trying out Devuan 6.X as my main OS version, and the problems I encounter are mostly not related to Devuan at all, but originate upstream.
The current problems I have, mostly come from post-install scripts. I think that doesn't have to take much resources to fix, but I have never been forced to go into that stuff before. I think that may be the first step in a process that may produce alternatives to some of the principle-breaking stuff :-)

Small update:

Nor did I, when Debian 13.3.0 and Devuan 6.1.1 behaved the same way.
But I couldn't get Debian 11.2.0 to work, it came up with the squashfs image, persistence was ignored running kvm.
This might, though, be an effect of the five remasterings done. So I started out with the squashfs from the ISO and a new persistence store.
Still didn't use the persistence volume, so here I have a  clear contrast between new 11.2.0 and 13.3.0 installs. Might still be unrelated to systemd, but scope creep always makes me suspicious when unexplainable errors occur.
For the purpose of running older versions in a vm, the obvious remedy is to squash the overlay file system into a new image.  Then it is enough to keep that, a few GBs disk space is saved, too.

BTW, here is the booting stanza for the Devuan instance I am running now:

title Devuan 6.1.1 64 bits Xfce live /dev/nvme0n1p6  v0  persistence/dev/nvme0n1p7  
      root(hd0,0) 
      kernel  (hd0,1)/boot/dev611/vmlinuz boot=live config quiet splash initrd=(hd0,1)/boot/dev611/initrd.img  bootfrom=/dev/nvme0n1p6  live-media-path=dev611/live0 persistence persistence-path=dev611nvme7/pers0 keyboard-layouts=no noautologin 
      initrd (hd0,1)/boot/dev611/initrd.img

Re bootloaders: Legacy grub was installed on the SATA disk by an OS version long gone. No need for any updating, I just add new directories with kernel&initrd images, and edit menu.lst. As long as I can run a version with legacy grub installed, I can repeat the procedure with new disks, and I do - it works with types of USB media and nvme-disks it had no idea about when first developed.
That's how a GRand Unified Bootloader should behave, in my head. So I wish for a GRUB-reinc (reincarnated legacy GRUB) with knowledge of GPT and loadable modules for UEFI navigations etc when absolutely necessary, kernel-style :-)

Small update:
It turns out that the method also works with a fresh Debian 13.3.0 Lxqt-version. I could use the same squashfs image there both for the native basis and the kvm instance, working on an overlay at another partition. So while this may have been systemd-related in the past, it doesn't seem to be now.
And it does of course not have to be the same squashfs image. Running Devuan under Debian or vice versa works just fine when starting with a clean 13.3.0-Debian version.

For administration and development, I can mount other drives read-only in the vm. For example, I have a large ext4 SATA partition  usually mounted on /store, and I can mount it read-only and use it for reading. For writing, I have the partition where the persistence volume is mounted. Which can be mounted read-only on the host to provide data traffic both ways in a simple and controlled manner.

I think this may be a useful environment for live development.
And there is no 'basic install' here. At the next boot, 'host' and 'vm' may swap roles. It is basically symmetric ;-)

This does not at all fit with my ca 13 yrs experiences with Debian live with persistence. And before that, a long time with Debian-derivative Knoppix.
Keyboard-layouts and autologin may surely be useful with persistence, so forcing them to be shut off doesn't make much sense to me.
There are lots of very different use cases where persistence is necessary or at least useful. So one size, in the way it is enforced here, does definitely not fit all.
But of course, software freedom is also for being very content with what is offered ;-)

For me, that's a buggy system. Because it violates the 'principle of least surprise'.
Hard-coding a username in a bootloader commandline is bad practice in my opinion. This should work well with only noautologin, and eventual privileges etc should IMO be fixed with a transparent CLI script.
Eventual transitions to persistence running should also be made transparently IMO. What are the advantages of doing this behind the scenes?