Not sure it'll make a difference, but the normal sequence is:
   to run "apt-get update" first, because that updates the local meta information to be current.
   thereafter you run "apt-get upgrade" to bring existing packages up-to-date as much as possible.
  finally you run "apt-get dist-upgrade" to also handle changing dependencies of new package versions, which may involve both removing and installing packages.

Does udev detect the device and install associated modules? What's in /sys/class/net/
What's in your latest boot dmesg?

I'm not sure what you take issue with... perhaps just that documentation on the web is old?

Otherwise I think one of the confusing aspects of ALSA configuration changes is that in general any program that use the audio system will end up loading an instantiating a configuration structure internally only once, when it starts. Therefore, such programs need restart after a change to the configuration source files, which include the user's .asoundrc file.

Though, a program may of course have been made to reload the configuration, and in that case such a program will do so as programmed and then rebuild the internal configuration structure from that on file.

I would suggest that old and bad documentation can only be remedied by writing new and better documentation; grumbling about what's existing and discussing it's badness is just waste of time.

Yes, and one thing that is confusing with ALSA is that programs typically loads the sound configuration only once, early during startup. Therefore such a change to the configuration only takes effect for programs that are started after the change.

There is a way to make a configuration have a dynamic part, to be automatically reloaded upon every sink (or source) creation instead, but then we are entering a deeper level of understanding of ALSA configuration structure and elements which most people rather wish to avoid.

Hmm I have a /.cache with two sub directories

drwx------  2 root root 4096 Jun 17 01:15 mesa_shader_cache
drwx------ 52 root root 4096 Jun 17 01:15 mesa_shader_cache_db

and then some directory tree down to pairs of files. All of that created and modified at that one time. Presumably mine belongs to some "mesa" package.

slower than what?

What do you get from rfkill  ? (you might need to install it).

@rwall, add some double-quotes, and make that line 17 be

if [ ! -e "${RC_SVCDIR}/softlevel" ]; then

and then you won't have that problem (at least).

(I assume "freer" is a misspelling)

I can't replicate the problem, but an access timeout may have many reasons.
Does the "same thing" happen every time?

How about we leave this thread here (without me actually closing it) as there is no value in adding opinions here one way or the other. If I get inspired I'll weed it and retain the technical matters for later.

Yes chimaera-backports came back. I think it got removed when bullseye-backports got removed; then bullseye-backports came back; and then after a while chimaera-backports came back. And during all that bullseye and chimaera also got archived. All done very much on purpose by Debian and Devuan "repository dev's"; I'm sure there is a story.

Perhaps it stays like it is for a while.

@steve_v: you still here? And you still contribute to the discourse?
You are too kind.

Well, at least half the population is above average IQ...