In the issues in #11535 I made reference to applying the Windows behavior of the app domain is the location of the symbolic link to Linux

[jhudsoncedaron]

I wrote: We had actually discovered the behavior was different on Linux and used a LD_PRELOAD to prevent the loader from noticing it was a symbolic link.

So the way this is fixed id clearly an LD_PRELOAD that intercepts realpath. When launching a binary via bash, _ is set to the path to the binary, which unlike /proc/self/exe is the symbolic link path. Other launchers don't do this and appear to expect you to look at argv[0] and the PATH environment variable. I found it most expedient to manually set _ in systemd unit files to get the bash behavior anyway.

Here are the comments from the implementation:

    /* Make sure _ is not stale */
    /* 
     * The dotnet launcher calls realpath on /proc/self/exe and again on the result thereof
     * and uses that to locate the entry assembly, for which it calls realpath on as well.
     */
    /* When resolving the entry assembly and runtimesettings, don't follow symlinks. Let the kernel do it. */

This results in realpath("/proc/self/exe") => getenv("_") but only where _ refers to a symbolic link to of the actual binary.
In addition, any attempt to resolve any path starting with /path/to/exename simply returns the path again. Thus the loader is completely fooled into thinking the symbolic link tree directory is the actual application domain directory.

For reasons that should be obvious; I would advise not trying to change the behavior so that _ is trusted as the correct value for everybody. (Likely to cause the opposite problem as #11535 for somebody else.) But I do wonder if the call that is realpath("/path/to/entryassembly.dll") is excessive.