Hi Jared,
In theory, you know the context at build time - it is $CONTEXT as shown here: Build environment variables | Netlify Docs
I’d think that means that your deployed function could know it, at build time, and embed the string (or related settings set based on the string) in the code we create during build, and thus no dynamic, runtime determinations would need to be made - all is set before execution.
I can’t speak to engineering challenges on adding things to function environment in our deployment process code, since I don’t work on that codebase, but I can speak to the practical problem for other customers with doing it which is what makes this idea not an obvious slam dunk and why wouldn’t we do it already?! Folks frequently run into AWS’ own limit on environment size (mentioned in the yellow box in this section of the docs: Functions overview | Netlify Docs) - which boils down to “AWS only accepts function deployments with up to 4k worth of environment variables, when appended in a string like VAR1=val1,VAR2=val2, and base64 encoded - more will cause the deploy to fail!” So, there is a definite pressure to preserve space in the environment and that will factor into anything we add: if we start adding things that folks can’t opt out of, we create other problems!
I see you did understand that you can do this based on later statements in your thread, and we can absolutely get our documentation improved to be more explicit on this topic, so I’ll work with the docs team on that! Thanks again for talking through this with us!