The file "~/.guix-profile/etc/profile" treats all search paths as
colon-separated lists.  Some variables are not supposed to be lists, but
treating them as such could confuse programs which read them.
GIT_EXEC_PATH is one that has caused me trouble, so I'll be using it as
an example below.

The relevant line from "~/.guix-profile/etc/profile":

% grep GIT_EXEC_PATH ~/.guix-profile/etc/profile
export GIT_EXEC_PATH="${GUIX_PROFILE:-/gnu/store/9wwv7rl8n6ydcpa0h22nd38amwssfrbh-profile}/libexec/git-core${GIT_EXEC_PATH:+:}$GIT_EXEC_PATH"

Here's what my GIT_EXEC_PATH looks like from a terminal emulator:

% echo $GIT_EXEC_PATH
/home/sankey/.guix-profile/libexec/git-core:/home/sankey/.guix-profile/libexec/git-core

Here's the error from git:

% git rebase
/home/sankey/.guix-profile/libexec/git-core/git-sh-setup: line 46: /home/sankey/.guix-profile/libexec/git-core:/home/sankey/.guix-profile/libexec/git-core/git-sh-i18n: No such file or directory

Since my shell rcfile is sourced twice, GIT_EXEC_PATH becomes a
colon-separated list.  Double-sourcing the shell rcfile may not be the
only way to surface this issue.  If my rcfile simply set GIT_EXEC_PATH
before sourcing "~/.guix-profile/etc/profile", then I would still end up
with a corrupt GIT_EXEC_PATH.

My workaround involves using `guix package --search-paths=exact`, but
this cost me some time debugging which I'd like to save the next person.
I am not sure what the solution should be.  Maybe just a clarification
in documentation?  What about an argument for search-path-specification
to force the variable to always be "exact"?

Troy