Incorrect environment loaded with combination of env_files/env_scripts

[quasi-coherent]

Describe The Bug

I am pretty sure this behavior is inconsistent with the documentation. Two profiles, each with the same variables set to different values in individual env_files that are scoped to the correct profile are being loaded in the order in which they appear in the array, regardless of what profile is set on the command line. This seems to contradict the sentence here

Load global environment files defined in the env_files attribute.

when taken together with the sentence here

Use the profile property to only load environment variables whenever a specific profile is active.

To Reproduce

I have two profiles, say, cicd and local. They have scoped env files:

env_files = [
    { path = ".env/make.env" }, # global values that don't clash and are not relevant 
    { path = ".env/cicd.env", profile = "cicd" },
    { path = ".env/local.env", "profile" = "local" },
]

These declare the same environment variables but with different values:

# cicd.env
POSTGRES_HOST=postgres
POSTGRES_PORT=5432
POSTGRES_USER=asdf
POSTGRES_PASSWORD=asdf1234!
POSTGRES_DB=my_db

# local.env
POSTGRES_HOST=dockerhost
POSTGRES_PORT=5438
POSTGRES_USER=asdf
POSTGRES_PASSWORD=asdf1234!
POSTGRES_DB=my_db

Then I need to do some manipulation of these to define environment variables needed for some tasks that can run for either profile, e.g.,

env_scripts = [
'''
#!@duckscript

profile = get_env CARGO_MAKE_PROFILE
test_profiles = get_env TEST_PROFILES
handle = split ${test_profiles} ";"
is_test_profile = array_contains ${handle} profile

if is_test_profile
    suffix = get_env EPOCH
    pguser = get_env POSTGRES_USER
    pgpass = get_env POSTGRES_PASSWORD
    pghost = get_env POSTGRES_HOST
    pgport = get_env POSTGRES_PORT
    pgdb = get_env POSTGRES_DB
    test_pgdb = set ${pgdb}_${suffix}
    pgurl = set postgres://${pguser}:${pgpass}@${pghost}:${pgport}/${pgdb}?sslmode=disable
    test_pgurl = set postgres://${pguser}:${pgpass}@${pghost}:${pgport}/${test_pgdb}?sslmode=disable

    set_env DATABASE_URL ${pgurl}
    set_env TEST_DATABASE_URL ${test_pgurl}
end
'''
]

where I've got these global blocks:

[config]
default_to_workspace = false
skip_core_tasks = true
additional_profiles = ["local", "cicd"]
init_task = "init"
end_task = "end"

[env]
TEST_PROFILES = ["local", "cicd"]
EPOCH = { script = ["data +%s"] }

I have the task

[task.env-test]
condition = { profiles = ["local", "cicd"] }
script = '''
echo ${CARGO_MAKE_PROFILE}
echo ${DATABASE_URL}
echo ${TEST_DATABASE_URL}
'''

Output:

> $ cargo make --profile local env-test
[cargo-make] INFO - cargo make 0.37.16
[cargo-make] INFO - Calling cargo metadata to extract project info
[cargo-make] INFO - Cargo metadata done
[cargo-make] INFO - Build File: Makefile.toml
[cargo-make] INFO - Task: env-test
[cargo-make] INFO - Profile: local
[cargo-make] INFO - Running Task: env-test
local
postgres://asdf:asdf1234!@dockerhost:5438/my_db?sslmode=disable
postgres://asdf:asdf1234!@dockerhost:5438/my_db_1731714400?sslmode=disable
[cargo-make] INFO - Build Done in 2.25 seconds.

> $ cargo make --profile cicd env-test
[cargo-make] INFO - cargo make 0.37.16
[cargo-make] INFO - Calling cargo metadata to extract project info
[cargo-make] INFO - Cargo metadata done
[cargo-make] INFO - Build File: Makefile.toml
[cargo-make] INFO - Task: env-test
[cargo-make] INFO - Profile: cicd
[cargo-make] INFO - Running Task: env-test
cicd
postgres://asdf:asdf1234!@dockerhost:5438/my_db?sslmode=disable
postgres://asdf:asdf1234!@dockerhost:5438/my_db_1731714628?sslmode=disable
[cargo-make] INFO - Build Done in 2.40 seconds.

The host:port is incorrect for the chosen profile; it should be postgres:5432.

If I change the order of how they appear in env_files, it echoes values from cicd.env. While the documentation does say,

Paths to environment files can also be defined globally in the env_files key of the Makefile.toml, which will be loaded in the order they are defined.

given the wording in the section below that on profile-scoped env_files, I expect that the presence of a --profile would make the ordering irrelevant, as it should only load something scoped to the profile specified or an env_file without a profile.