Thanks! I downloaded it and will start using it.  I think you can stop calling yourself a non-maintainer.

Maybe

sudo chown -R root:root /usr

That should fix most if not all of it. AFAIK there's no wheel group in debian-based systems. For future reference, changing ownership on system files should be done carefully ans sparingly. Changing ownership of everything in /usr recursively is extremely bad advice. You relied on a friend who routinely lies, cheats and steals.

I got an answer from another party. You didn't do anything wrong. The raspberry pi has a hardware bootloader that boots the kernel binary directly. The package manager doesn't know anything about it and that's why you couldn't upgrade the kernel. I don't know if there's a way to manually upgrade it.

Maybe there's a problem with the edit you made to 90-alsa-restore.rules. I think "append" is not the right thing to do. There's a one-line replacement needed. It should look like the following.
Note: If you don't want it to be overwritten on update, put it in /etc/udev/rules.d instead of /usr/lib/udev/rules.d.

# do not edit this file, it will be overwritten on update

ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="/usr/sbin", TEST=="/usr/share/alsa", GOTO="alsa_restore_go"
GOTO="alsa_restore_end"

LABEL="alsa_restore_go"

ENV{ALSA_CARD_NUMBER}="$attr{device/number}"

# mark HDA analog card; HDMI/DP card does not have capture devices
DRIVERS=="snd_hda_intel", TEST=="device/pcmC$env{ALSA_CARD_NUMBER}D0p", RUN+="/bin/sh -c 'echo ALSA_CARD_HDA_ANALOG=$env{ALSA_CARD_NUMBER} >> /run/udev/alsa-hda-analog-card'"

# check for ACP hardware
TEST=="device/device/acp3x-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp6x-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp63-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp-dmic-codec", GOTO="alsa_hda_analog"
GOTO="alsa_restore_std"

LABEL="alsa_hda_analog"
# restore configuration for profile with combined cards (HDA + digital mic)
TEST!="/run/udev/alsa-hda-analog-card", GOTO="alsa_restore_std"
IMPORT{program}="/usr/bin/cat /run/udev/alsa-hda-analog-card"
ENV{ALSA_CARD_HDA_ANALOG}!="", ENV{ALSA_CARD_NUMBER}="$env{ALSA_CARD_HDA_ANALOG}"

LABEL="alsa_restore_std"
TEST!="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore $env{ALSA_CARD_NUMBER}"
TEST=="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime nrestore $env{ALSA_CARD_NUMBER}"

LABEL="alsa_restore_end"

I got that yesterday on a youtu.be link. After going through several screens of bicycles and busses (and clicking on every box that did NOT have what they asked me to identify) I clicked on boxes to form letters, one for each screen. Total of 7 letters, two words, to tell them how I felt about it.

Then I switched from firefox-esr to tor-browser and got right to the page I wanted.

Using a non-standard port for ssh (or any service) doesn't work as well as it used to. If your server is exposed to the internet, it's just a matter of checking your IP address to see what ports you have open.
Search here: https://search.censys.io/

Main menu:
Applications -> Settings -> Removable Drives and Media
Then check appropriate boxes.

Thunar file manager:
Devices should show up in the left side panel. I don't recall if I had to change any settings to get that. That would either be in Edit -> Preferences or View.

It's linux. There are 10 ways to do anything. Pick one.

If you have a root account, you can su to root to do admin tasks. If you don't have a root account, you need to use sudo to do admin tasks, and in that case, you're probably a member of the sudo group and can do anything with it.

The original intent of sudo was to allow fine-grained permissions for certain users or groups to do a few specific admin tasks rather than give them total root access.

What you should not do is log into a desktop session as root.

What is says is that if you want to use sudo to run a command in /usr/local/(s)bin, you must now give the full path to the command.

What I see is that I do not have to give the full path to run the command with sudo, but maybe that's because I have the full path to the command already in my /etc/sudoers.d/usercommands. So for me, there's no change. Tested this in freia with the version of sudo mentioned above.

Confirmed.

task-lxqt-desktop and sddm are installed, but there are no lxqt packages installed. Boots to console login. And 'startx' seems to be missing, although there are xorg packages installed.

I've installed lxqt in freia a few times previously, but always after a base (no-X) install. This is the first time I've tried selecting lxqt from the tasksel menu, so I don't know if this is a new behavior or not.

apt install lxqt brings in a lot. (Total 1477 packages) It looks like everything is there now.