- Why is it a variable initialized at startup and not a procedure that
gets the up-to-date value?
The key to understanding exec-path is that setenv() is not exported by this SRFI, so the value is guaranteed never to change, provided the user doesn't make use of setenv() through some other interface. However, I provide the warning in case the user can and does tamper with the environment. Note that setenv() is not guaranteed to work.
Generally speaking, I'd rather expose a constant value as a variable (which can't change outside the library it's defined in) than as a procedure.
- In what situations would a programmer want to consult exec-path-list
instead of (getenv "PATH") or an (exec-path-list) procedure?
It's more convenient than (getenv "PATH"). See above for my reasons for making it a variable.
But if people think it should go, I have no problem with removing it.