Env recipe attribute improvements/features

[GeorgeLS]

I tried searching for existing issues around env variables and I believe I couldn't find something similar.
Today, as I was implementing a justfile I came across two use cases that I believe make sense and would be useful if supported.
I'm not sure if you would like two separate issues for those or even if you would like something like this but here are the use cases:

env attribute with override behavior

The env related functions have different variants based on the behavior you want: env: try getting from the host env or use the specified as default, env_var_or_default: same as env but with explicit intent, env_var: try getting from host env or fail. Now, I would expect for the env attribute to behave as the env function which it doesn't. I think that changing the behavior of env attribute to match the behavior of the function is a breaking change in terms of semantics and might confuse users. Are you open to the idea of introducing a env_var_or_default (or however you might like naming it) attribute that implements that behavior? I find this to be useful in cases where you might want to have a default env variable exported as part of the recipe but be able to override it as well. You might say that if you pass the env variable externally when executing the recipe, what is the point of having the attribute? I will agree but the problem is that you might want 90% of the time to use a default one and if you do, then overriding that externally doesn't work since the recipe defined one acts as an override at the time being.

interpolation support on env attribute

Now, I think that is the most valuable one compared to the one mentioned above.
There are cases where I might have different recipes and I want to use the same env variable name and value for all those recipes. Each recipe is doing something different but all of them require the same information. Usually env variable names are quite short but the values can be big sometimes. Also, this isn't only about name/content length and the fact that I might be lazy to copy paste. It solves the problem of keeping data in sync. If I have to change the value in one recipe, then I have to change it everywhere. It would be really good to be able to do something like so:

var_value := "some env variable value"

[env("SOME_VAR", "{{var_value}}")]
recipe1:
    ...

[env("SOME_VAR", "{{var_value}}")]
recipe2:
    ...

and also be able to do the same for the variable name itself:

var_name := "SOME_VAR"
var_value := "some env variable value"

[env("{{var_name}}", "{{var_value}}")]
recipe1:
    ...

[env("{{var_name}}", "{{var_value}}")]
recipe2:
    ...

Right now, if you do that, the value is treated as a literal string and that's what is being exported.
Semantically, this makes sense and I think that is the behavior that should be preserved.
For example, a user might as well want to pass {{var_value}} as a literal string for their env variable value. As for the name, I'm not sure even if such a name would be accepted and it would definitely be very weird to work with when trying to expand it on a shell.

I believe a better approach to this would be to be able to specify those not as string literals. Like so:

var_value := "some env variable value"

[env("SOME_VAR", {{var_value}})]
recipe1:
    ...

However, if you attempt this today, it will fail during parsing. If we want to go with this direction, we would need to treat those specially during parsing.

One last argument you might have is to export the env variable at the top of the file but I might not want the env variable for all of my recipes present.

Open for discussion and thoughts.