I'm not sure about "technical expertise", as most of the stuff you learn while doing this is highly specific, but perhaps the real expertise is having the toolset and determination to do this at all. To keep taking screws out of the system and removing the covers until you find out where the system makes a particular decision. Fortunately in this case you can go to the source; if you can't, or as a first attempt, strace will usually tell you where a particular program gets its information from. Harder to use here as you'd need to setup the login process itself with strace and there's privilege boundary considerations.
One observation I would make is how many layers of "plugin architecture" have been added here. Probably the original SysV login program just printed /etc/motd. Now we have PAM, and pam_motd itself also runs a bunch of tiny plugins, some of which also refer across to systemd.
I should probably write up some of my own deep-dive debugging stories, if I can still remember enough detail. The "why does structured exception handling sometimes not work on Windows CE" was a particularly time consuming one which involved disassembling bits of Windows kernel.
One observation I would make is how many layers of "plugin architecture" have been added here. Probably the original SysV login program just printed /etc/motd. Now we have PAM, and pam_motd itself also runs a bunch of tiny plugins, some of which also refer across to systemd.
I should probably write up some of my own deep-dive debugging stories, if I can still remember enough detail. The "why does structured exception handling sometimes not work on Windows CE" was a particularly time consuming one which involved disassembling bits of Windows kernel.