>> One thing that still puzzles me is exec-path-list. It's a variable that
>> mirrors the value of the PATH envar, but "changing the value of PATH may
>> or may not not change the value of this variable" so you can't trust it
>> when reading it. What are the intended applications of this variable?
>
> I can't answer to the latter, but for a static version, on top of a
> Scheme that implements get-environment-variable and the regex SRFI-115,
> it's a line of code, plus a bit more for Window's use of ";" for
> pathname separation in the PATH environment variable.

Implementing it isn't hard but why are the semantics what they are:

- Why is it a variable initialized at startup and not a procedure that
gets the up-to-date value?

- If speed and/or space are problems and the implementation can assume
that PATH doesn't change during the process lifetime, it can memoize the
value of an (exec-path-list) procedure.

- "The spawn-path variant searches the directories in the value of the
environment variable PATH" so that one uses the real up-to-date value of
PATH anyway.

- In what situations would a programmer want to consult exec-path-list
instead of (getenv "PATH") or an (exec-path-list) procedure?

- A (split-path string) procedure and a (getenv) procedure might be more
useful, but I concede that that encroaches on pathname/envar territory a
lot.

I've hacked in Emacs Lisp quite a bit, and Emacs has an exec-path
variable just like this (but the user is free to change its value at any
time). It's not without its problems and personally, I wouldn't vouch
for something like it.