xref symlink indigestion

[James K. Lowden]

With 25.1 installed, I'm happily using xref.  I noticed something
slightly odd, and wonder what might be done for it.  

On my system $HOME/projects is a symbolic link:

$ file ~/projects
/home/jklowden/projects: symbolic link to /usr/local/projects/

I rely exclusively on the symbolic link, and start emacs as a daemon
there.  At the moment I have two daemons running (under different
names) for two different projects.  When I use M-x pwd in the
*Messages* buffer, it reports the symlink path: 

        Directory /home/jklowden/projects/csv2bin/

When I use xref-find-definitions to load a file, though, it loads it via
the non-symbolic path.  If I open the file per usual (in the project
directory, via the symlink) and then use xref-find-definitions, I see a
message like 

        /usr/local/projects/csv2bin/mapcols.h and 
        /home/jklowden/projects/csv2bin/mapcols.h 
        are the same file

which indeed they are.  

Why is xref insisting on using the non-symbolic path?  The TAGS file
doesn't mention it.  The daemon's current working directory is on the
symbolic path.  Files opened with emacsclient on the symbolic path
behave normally (i.e., their names reflect the symbolic path).  

I suspect something somewhere is gratuitously calling realpath(3),
doubtless with good intentions.  I'd like to understand why, and see if
there's a better way.  

--jkl