Arch Linux

Well you configured to use local libraries, if I understand your text correct. So it does exactly do what you have configured, include custom libraries.

I didn't configure it to cause a kernel panic, did I?. I am a c/c++ developer, and Arch Linux is my primary dev environment. Needless to say, I am always compiling and testing various libraries which shouldn't be installed system-wide, but contained either in /usr/local or ~/.local; I believe that's the main purpose of those directories, right? I have no problem with local libraries being included in initramfs, but having them cause a kernel panic should be considered an aberrant behavior; every time I update Arch Linux,I end up with a useless system which requires me to boot from the USB, chroot into the failed environment, update my linker config, and re-generate initrams manually with "mkinitcpio -P". Thanks.

Just to quote your action:
2. add ~/.local/lib to /etc/ld.so.conf.d/99-local.conf
You explicitly add those paths to replace the system wide ones.
So it's your custom configuration which blows your system.

Yes, that's my workflow. However, in my opinion, having a functional (bootable) initrams should be considered a greater priority than some userspace libraries.

Unconditionally overriding system libs is the problem here, not mkinitcpio.

Setting LD_LIBRARY_PATH or LD_PRELOAD specifically when testing is the way to do what you want. Doing that globally is just asking for all kinds of probolems.

I'd probably consider looking at `meson devenv` which would help you override `LD_*` variables as needed.

https://www.collabora.com/news-and-blog/blog/2022/03/30/spotlight-on-meson-full-featured-developer-environment/

I don't see how this is a `mkinitcpio` issue.

Maybe the issue is not strictly related to "mkinitcpio", but it is definitely an Arch Linux issue worth mentioning. I've been using Fedora, Debian, Ubuntu, and Gentoo for a long time and I have never experienced any issues with local libraries. Feel free to close this issue if you think it's not really an issue.

Would it not make sense to have mkinitcpio not respect these ld overrides by default?
I spent the best part of my afternoon figuring out why kmod couldn't find libcrypto.so.3 while I saw it plain and perfect in /usr/lib.
In my case it was an AUR package which added such an override in /etc/ld.so.conf.d: https://aur.archlinux.org/packages/dell-command-configure
Yes, it's definitely bad for a package to do that kind of thing. And I'm glad I found this override, as it meant lots of my system would be using an out of date libcrypto.

But it's also bad of mkinitcpio to generate a broken init image by
1) taking into account these ld.so overrides at generation time
2) not taking into account these overrides when actually booting, as the init environment could not find the libraries mkinitcpio thought it needed to include...

I would appreciate that such an inconsistency in mkinitcpio is resolved, even though I agree the current result could ultimately boil down to "user error".
It's just quite a leap to realize that /etc/ld.so.conf.d content can break init image generation in an otherwise perfectly functioning system.