I did try it. Didn't work in combination with env.
# Sets PWD and SHLVL and the latter apparently can't be unset
env -i VARIABLE=value bash -c 'exec -a program ./program'
# Sets env's argv0, not my program's
bash -c 'exec -a program env -i VARIABLE=value ./program'
# SHLVL still set
env -i bash -c 'unset SHLVL; unset PWD; exec -a program ./program'
# SHLVL and _ still set
env -i zsh -c 'unset _ HOME PWD LOGNAME SHLVL OLDPWD; ARGV0=program
To test my programming language. It's a freestanding lisp interpreter that doesn't link to libc. I wrote the code that handles the environment variables and in order to test it I needed full control over the program's inputs including its environment. The env utility provides this control by emptying the environment and setting only the variables I specify, solving 90% of the problem. Only thing I still can't control is argv[0]. With this new feature upstreamed, my test suite will be complete.
I did not know about that possibility! It requires glibc and its dynamic linker though, doesn't seem to be as widely available as the GNU coreutils. I developed lone inside Termux: it does not have ld.so but does have env. There's a GNU binutils ld but it did not recognize the --argv0 option when I tried it.
ld.so is the dynamic linker. It is always used when invoking a dynamically linked program but you can invoke it manually which allows you to specify optionsfor the linker. But the name and path you need to invoke depends on the architecture and possibly distro, e.g. for amd64 these days its
https://lists.gnu.org/archive/html/coreutils/2023-03/msg0000...
https://lists.gnu.org/archive/html/coreutils/2023-03/msg0001...