Here is a simple CLI that mixes auto-generated and multiple environment variables:

from click import command, echo, option, pass_context

@command(context_settings={"auto_envvar_prefix": "yo", "show_default": True})
@option("--flag/--no-flag", envvar=["FlAg", "sUper"], show_envvar=True)
@pass_context
def my_cli(ctx, flag):
    echo(f"Flag value: {flag}")

if __name__ == "__main__":
    my_cli()

This produces the following help screen:

$ python ./multiple_envvars.py --help
Usage: multiple_envvars.py [OPTIONS]

Options:
  --flag / --no-flag  [env var: FlAg, sUper; default: no-flag]
  --help              Show this message and exit.

Now let's try a couple of different envvars:

$ FlAg=1 python ./multiple_envvars.py
Flag value: True

$ FlAg=0 python ./multiple_envvars.py
Flag value: False

$ sUper=1 python ./multiple_envvars.py
Flag value: True

$ sUper=0 python ./multiple_envvars.py
Flag value: False

$ yo_FLAG=1 python ./multiple_envvars.py
Flag value: False

$ YO_FLAG=1 python ./multiple_envvars.py
Flag value: True

$ YO_FLAG=0 python ./multiple_envvars.py
Flag value: False

The surprise here is the discovery process of the auto-generated YO_FLAG. I expected it to respect the case-sensitivity of others. but everything auto-generated is uppercased.

So I wonder if we should enforce upper-casing all env vars, whatever their source.

And additionally, shouldn't we add the auto-generated YO_FLAG to the help screen to improve discoverability?

For reference, I ran these test on macOS / zsh, and with the latest click 8.3.1.