Can you use unexport to avoid polluting sub-shell environments?

unexport ENV

Thanks for your response. Well, any interaction manually managing shell vars is what I am avoiding for the same reason: it means humans making mistakes from settings which are out of sight in a terminal session on their machine.

We can assume we already have indicated what env we intend with afeldkamp's example current_project := gcloud config get project which is quite deliberately delegating the decision - this avoids duplicate and potentially contradictory paths.

I understand the just utility hasn't been designed with "basically" global variables in mind so it's not a simple ask. This is why I mentioned supporting user defined flags as another way to avoid requiring shell variable handling outside of the justfile such as just test -e dev. Perhaps something as simple as only adding -e <envString> support would satisfy my requirements nicely - although it doesn't satisfy the case of delegation - that's of secondary importance from my POV. Thanks.

Oh, one other thing, you can override just variables on the command line by putting the overrides after just but before any arguments:

just ENV=dev test

In the above command, ENV is a just variable and not an environment variable. Does that work?

Thanks for your reply.  I don't see how I can load an environment file globally using that: x'$ENV'.sh <-- error: Shell expansion failed: error looking key 'ENV' up: environment variable not found 

This example by afeldkamp is an example of what I am looking for.  It feels like to me that just variables are not first class citizens and this leads to reliance on env variables.  And yet, I can't turn this ENV variable into something useful because  set dotenv-filename won't work with just vars as in the below

set dotenv-filename := "{{ENV}}.env".  # error

Maybe I could call another recipe in the dependency of every recipe to set up variables for global env settings... IDK if that would work.  Overall, variable scope limitations are coming up against just var vs env var quirkyness, meets up against variable file loading limitation, meets command line argument passing limitations, and something basic like this IMHO shouldn't be that hard in what seems otherwise a very useful tool.  
- What about support for sub-recipies to allow variable sharing?
- What about supporting a getopts style of variable passing on the command line?  (with an option to allow them to be environment vars OR just vars via setting).
Thanks.

Ah, sorry, you're right. Yah, just environment variables won't work there.

Can you do just -E dev.env test to load the dev environment? This avoids needing to set an environment variable, and is very close to just test -e dev which you suggested above.

Thanks for help with a good option; I will try it. 
I'm content to close this issue, but, overall would like to point out the following.
- Due to the name of this utility, there is an implied lean in to natural language - can that be denied? However, due to the limitations of handling command line options, positional parameters and env vars vs justvars etc.. (all things mentioned above and by others), command line constructs that look and feel natural and memorable are few and far between in reality.  Your latest suggestion is a case in point,  just -E dev.env test is not at all natural, and really can't compare to just test -e dev. So, I may have missed the point, but, the expectation that I wouldn't need to write fancy shell wrappers to avoid awkward command lines seeped into my head when I wanted to evaluate this tool.
Thanks for your time.