Wow. Sometimes doing silly things pays off. Like wanting to type LWinKey-"a" and get an 𝐚.
Now, mathbold lowercase "a" ("𝐚") is code point U+1D41A. It seems loadkeys (from kbd-utils project) does not like that. The Devuan kbd is version 2.3.0-3.

lhp@xanadu:~/sandbox/kbd$ apt list --installed|grep kbd
kbd/stable,now 2.3.0-3 amd64 [installed]

I checked out kbd from https://github.com/legionus/kbd and compiled it.
The Devuan loadkeys gives this message:
lhp@xanadu:~/sandbox/kbd$ sudo loadkeys -v -C /dev/tty5 ~/cached_UTF-8_del.kmap
Loading /home/lhp/cached_UTF-8_del.kmap
too many (144) entries on one line

The presumably most recent version I built from source gives:
lhp@xanadu:~/sandbox/kbd$ sudo src/loadkeys -v -C /dev/tty5 ~/cached_UTF-8_del.kmap
Loading /home/lhp/cached_UTF-8_del.kmap
unicode keysym out of range: U+1d42a
syntax error, unexpected ERROR, expecting NUMBER or LITERAL or UNUMBER

So it was my silly tinkering, after all, that messed things up. (I'd argue that it should be possible to type any Unicode code point, but that's not for me to decide. I guess I'll write a suggestion for the kbd project though.)

Ah, it's so 𝐧𝐢𝐜𝐞 to have my mathbold Unicode letters back. Turned out there was a typo in my symbols file. Mea culpa.

However, the system has regenerated the /etc/console-setup/cached_* files, and the new cached_UTF-8_del.kmap.gz still causes loadkeys to hiccup with "too many (144) entries on one line", and switching from X to a  console with Ctrl-alt-F5 I can see that the console is not using Danish keyboard layout. I believe it used to. Just checked on other machine, and sure enough it does have the Danish keyboard set for the Ctrl-Alt-F5 console on tty5.

So now I would like to look at how the cached_UTF-8_del.kmap.gz file is generated, and why TF it gets to be malformed. (It might still be related to my tinkering, of course.) If anyone can shed some more light on this, I'd be thankful, meanwhile I guess I'll cook a little Perl script to find the offending line with too many entries.

Well, that doesn't sound like a particular good way to do it, installing a whole unstable OS on another machine or a VM, and then also doing extra tricks to prevent other problems. Then I could just as well install a VM with NetBSD, as it seems pkgsrc has Inkscape 1.2.2 already. I was hoping for an easier solution, for something that should really not be a problem, or at worst a trivial one. It is a bit like if I said the sprinkler on my car isn't working, and the proposed solution was to replace the gas engine with a diesel and repaint the car orange.

I vaguely remember now, having had to solve this problem before, more than a decade ago; I think the solution was some package like pdfposter or PosteRazor, but not one of them. Possibly it was poster and I did the exercise in PostScript and not PDF. I'll give that a try for now, but better suggestions will be warmly welcomed.

I'm a very new Devuan user, but I guess I could claim being a VUA, having been root on 7 different Unix variants (not counting different Linux distributions) since the early 1990s. Isn't this just a matter of writing a tiny shell/awk/Perl script and/or perhaps setting up a little LDAP server and doing some /etc/nsswitch.conf configuration? Or maybe just good old NIS/YP? You could even distribute /etc/passwd (shadow, group) in a pinch?