Indeed these are all valid points, and as a zsh user myself I certainly considered the alternative shell issue. That said, if it were at all possible, through a combination of os.environ / shlex, subprocess, and even `source` if necessary, to offload this interpretation to the user's shell (pass the shell a given string, receive its interpretation first before further processing), I could see a lot of benefit from this. 

Relatedly, I have seem similar requests for environment variable support in configparser, here: http://grokbase.com/t/python/python-list/03ckhw75xr/parsing-environment-variables-in-configparser-files

This particular proposal is interesting in that it creates an intermediary between the file's environment variable syntax and the shell's own. Presumably if you standardized the presentation of environment variables within this file you could use os.environ once you had recognized it. 

That said, I can understand, however, if this is prohibitively costly to implement, and it may well be that this option is ill suited to the task I am putting it to.