Let me drop two tidbits as a matter of background knowledge:

a) the domain name deb.devuan.org, which is the right one to use, resolves into a collection of alternative IP addresses (ipv4 and ipv6). During any apt operation, every server request will use some IP from that list, and then that server will be the one providing the response to that request.

b) the apt system has meta-information files that tells "where" (in networking sense) the packages are. For Devuan those URLs include some forked packages that are directly served from Devuan package pool mirrors, and a majority of packages that Devuan mirrors handle by means of redirect URLs, to be served by Debian's package pool mirrors.

Your reported case for example shows that chromium  is not forked but retrieved via such a redirect, and apparently that redirect pin-pointed http://debian.bio.lmu.de as redirection target. I.e., the Devuan mirror that was picked offered that redirect, and evidently there was some issue with access to 2001:4ca0:4300::1:22 (aka http://debian.bio.lmu.de)  at that time.

Which iso?

As the key issue was fixed without needing ISO remake, the trial remakes were removed.

Great. Welcome on board!
I'm probably doing things wrong yes, and need to retire.
We can rely on you taking over this?

Just in parenthesis: all the installers do still work fine as long as you avoid network mirror backing during installation. It of course means that you'll end up with a rather minimal system, but it's still one where you can use the manual patching (wget + dpkg) before using the network mirroring/access the first time.

I disagree: it's a totally useless question.

Obviously there has been some kind of process failure when everyone in the whole community, including you and Ogis1975 as well as myself, failed to notice that the repository key was about to expire.

You don't have to ask about that. Rather you should ask yourself: "how can I help in the future?" and then act towards that.

The first step would be to determine which, if any, installation use case(s) need attention.

You don't mention whether(/that?) you also re-created the block device (major:minor = 254:5) as /dev/dm-5?

I believe the next attempt would be to: a) deactivate that volume group, then b) manually remove spurious links for that volume group in /dev and /dev/mapper, and then c) activate it again.

That's on the assumption that the disk itself doesn't happen to contain some old LVM meta-data on the partitions. As you know, LVM writes stuff onto the partitions, and some of its admin scripts gets confused if there are even accidental remnants of old meta-data.

One step to deal with that would be to delete the physical volume from the volume group, then clear it fully, and then add it again.

The short answer would be that "experimental is not merged".

You may note that the sources.list point says /devuan experimental while there is no experimental section in /merged.

You may well add a sources.list point for Debian's experimental section but obviously you take full responsibility for whatever package mix you make from that. With the appropriate pinning it should be "safe".

You can usually determine which virtual terminal Xorg is using by:

$  pgrep -a Xorg

and if that says, say, vt07 you may shift to that with ctrl-alt-f7.
Or, if you have a command line, the root command

# chvt 7

will do the same.

Further, there is normally a /dev/ttyN set up for every virtual terminal N. Thus, you may use

$ ls /dev/tty[0-9]* | wc -l

to see how many virtual terminals are available.
I think that is a compilation setting for the kernel.

See e.g. man openvt and friends, and man Xorg (look for "terminal").

Maybe you mean:

# iwlist wlan0 scanning | grep -B1 ESSID