What was the bug that this issue & PR intended to fix? The stated rationale is:

Sometimes shell executable name (exe; e.g., zsh) might resolve to a different path than path to the login shell (exePath; e.g., /bin/zsh)

On Linux, at least, these are extracted from a running process's /proc/pid/exe, and will only resolve to different files if the original file has been removed or otherwise changed since the running shell-under-examination was started. The exe field will not be 'zsh' but rather '/bin/zsh'; and the exePath field will be identical or effectively identical, unless actual filesystem changes have happened since the process was started.

For example, on my desktop (Debian 'sid', different from the Termux I was reporting on in #2136):

$ fastfetch -l none -s shell --format json
[
  {
    "type": "Shell",
    "result": {
      "exe": "/bin/bash",
      "exeName": "bash",
      "exePath": "/usr/bin/bash",
      "pid": 2981054,
      "ppid": 2980847,
      "processName": "bash",
      "prettyName": "bash",
      "version": "5.3.3",
      "tty": 6
    }
  }
]

Here, indeed, exe and exePath are 'different'; but this is because /bin and /usr/bin are the same directory on this system. /bin/bash has come from my account's /etc/passwd entry; the kernel decodes the same exact file's full name as /usr/bin/bash in the process's /proc entry:

$ ls -l /proc/$$/exe
lrwxrwxrwx 1 filbo filbo 0 Jan  8 18:07 /proc/2981054/exe -> /usr/bin/bash

But these (/bin/bash and /usr/bin/bash) are precisely, identically, the same file. It does not matter which one is invoked to query bash --version.

I don't think this change (5d13389) can have fixed an actual behavior bug; and instead it introduced one, since it causes fastfetch to try to follow nonsense ' (deleted)' links in some real-world scenarios.