This is caused by a behavior change of the kernel code controlling the LED to only turn on the LED when all inputs, including e.g. the jack mic input are turned off in the alsa-mixer settings.

But most userspace code only turns the mic which it is actually using on/off when you hit the mic-mute hotkey.

Also see: https://bugzilla.redhat.com/show_bug.cgi?id=2134824

Which is the same bug.

There is a set of fixes available in the form of an alsa-ucm update which tells the kernel to ignore the state of the jack mic input restoring the old behavior:

https://git.alsa-project.org/?p=alsa-ucm-conf.git;a=commitdiff;h=79a8ec44d3dcf097f4a4492c506cbcf338324175
https://git.alsa-project.org/?p=alsa-ucm-conf.git;a=commitdiff;h=9ce9ddb4a84fb467602b716575ea1d8f2bab0c39

The easy way is to ask your distro to update the UCM configuration to the recent one.

Note that all previous kernels have a bug which may cause that the microphone LED is not updated correctly with the sof-hda-dsp driver. Just plug something to the analog jack on your system and mute/unmute/mute the analog input. The microphone LED will follow those changes, too. So you cannot trust the state for the old kernels anyway.

On my Lenovo z13 Gen1, I believe I also have this same issue, the issue was filed in the my distro's bugtracker here:
https://bugs.archlinux.org/task/71768

The advice given at the bottom of that page seems to work fine as a temporary workaround:
> As a workaround, you can apply the correct trigger on every boot by creating
> a file /etc/tmpfiles.d/micmute-led.conf with the following contents:

> w /sys/class/leds/platform::micmute/trigger - - - - audio-micmute


Is the guidance still that there's nothing that can be done on the kernel-side to remediate this issue and that it's reliant on the distro to sort this out? If so, I can re-open the issue downstream with them.

I just checked, and it seems like Archlinux is already shipping the updated alsa-ucm with both of the above patches. So there is possibly something else going on?

The above settings is not related to the sound driver but to the LED driver. The audio-micmute trigger should be set by default in the kernel for the micmute led. See:

  ./platform/x86/thinkpad_acpi.c:
        {
                 .name           = "platform::mute",
                .max_brightness = 1,
                .brightness_set_blocking = tpacpi_led_mute_set,
                .default_trigger = "audio-mute",
        },
        [LED_AUDIO_MICMUTE] = {
                .name           = "platform::micmute",
                .max_brightness = 1,
                .brightness_set_blocking = tpacpi_led_micmute_set,
                .default_trigger = "audio-micmute",
        },

So the question is why the defaults are not set for your kernel.

What does say 'readlink /sys/class/leds/platform\:\:micmute/device/driver' ?

It returns:

> ../../../bus/platform/drivers/thinkpad_acpi

So the code in comment#5 is the right one. You may try to find, why the default trigger is not active by default on your system for micmute.

Would this commit explain the behavior? This was the commit listed in the archlinux issue that I linked above:

https://github.com/torvalds/linux/commit/e2da5ff435d64b59880648269c136484bea5c312?diff=split

An interesting thing to note is that adding the line to my /etc/tmpfiles.d/micmute-led.conf solved my issue, but I have no subsequently removed that line and the issue is still seemingly resolved, even persisting through reboots.

I have now***