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.)

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.

However, after a reboot, both the console and XFCE keyboard seem stuck as US even if the Keyboard Settings show DA (Danish). So now I am debugging this problem. While doing so, I noticed an error message at boot time. From /var/log/boot:
Setting up keyboard layout...too many (144) entries on one line

However this seems to have happened on previous reboots as well, so it is probably unrelated to my tinkering. It may be worth looking into anyway, perhaps.
I don't know why setting up the console keyboard need to be so convoluted, but anyway, AFAICT, it does the following:
/etc/init.d/keyboard-setup # is run by init, obviously. It then runs (if given start or similar arguments)
/lib/console-setup/keyboard-setup.sh # which either checks if a cached command exists
/etc/console-setup/cached_setup_keyboard.sh # which it then runs, otherwise it does setupcon -k

The /etc/console-setup/cached_setup_keyboard.sh script checks if /run/console-setup/keymap_loaded exists, deletes it and exits if it does, or if it doesn't it runs kbd_mode '-u' /dev/ttyn on tty1 to tty6. After that it loads a cached keyboard map with the command:
loadkeys '/etc/console-setup/cached_UTF-8_del.kmap.gz' > '/dev/null'

This file looks very strange, with loads of repetition, which I find hard to believe can be quite right.

Looking at a different machine (eldo), which has roughly the same config, but hasn't been tinkered, I just did a dumpkeys and  compared it with a dump on this machine (xan).
$ diff xan_kmapdumped eldo_kmapdumped
3,4c3,4
< number of keymaps in actual use:                 7
< of which 0 dynamically allocated
---
> number of keymaps in actual use:                 128
> of which 121 dynamically allocated

something isn't right, I guess. Next, I'll be comparing the cached files on  both machines, and see what's going on.

Now this is what I don't get: I can't find any documentation that says loadkeys will accept a gzipped keymap file, and looking at the source files does not seem to support this either. At this point I don't know what's going on anymore; my investigation in the main problem (with my tinkering) will probably take priority. But if anyone can point to a good explanation of how all this keyboard initialisation at boot works, it would be appreciated. I know this is most likely unrelated to the problem I caused by my tinkering, which I am aware that I have to debug in the context of X11/XFCE4 instead. However, the error message caught my eye, and made me curious.
Oh, and if you think I should be punished for my silly tinkering, I can assure you that typing this with a Danish physical keyboard and a US layout was not pleasant. ;-)