In setenv, why make the label optional ? I'm never going to remember the default so I rather read what is going to happen "in place" -- it is also explicit in setenv(3).

C doesn't exactly have optional arguments (though I take the point that the Unix functions tend to correlate with the underlying function, then counter that with the fact Unix.putenv doesn't correlate either!). I interpret a function with "set" in the name (with no argument) as meaning "set the value" (so overwriting implied) - to be honest, I find the existence of overwrite to be pretty odd (although I can see its occasional value).

All that said, I don't have a strong opinion...

I find the existence of overwrite to be pretty odd (although I can see its occasional value).

Another option would be to drop it.

A general design principle for the Unix library: when popular C standard libraries expose different ways to do the same thing, we expose only one function in unix.mli and choose between the various available C implementations in the C stubs. See for example lockf and fcntl(F_SETLK, ...).

So, we will definitely not expose both Unix.setenv and Unix.putenv.

What is the problem with Unix.putenv? The missing overwrite argument that setenv has? The name? Something else?

If you're curious why Unix.putenv is currently implemented with putenv and not with setenv, that's only because Microsoft's CRT implements the former but not the latter.

The problem is that we have the API of setenv with the warts of putenv:

• Unix.putenv accepts = in the key (although getenv doesn't care)
• Unix.putenv key "" on Windows is actually unsetenv

I don't mind putting the corrections in putenv, but I have been told before of a similar sin in Perl's use of C functions (which is why I suggesting adding the superior setenv and deprecating putenv), and the changes are incompatible with the previous interpretations of Unix.putenv, which was why I opted for that. I don't care at all about the overwrite, but we have optional parameters!

If you're curious why Unix.putenv is currently implemented with putenv and not with setenv, that's only because Microsoft's CRT implements the former but not the latter.

Really? You committed the version in unix 11 days before it was added to win32unix 😉

Some one was asking about unsetenv in https://discuss.ocaml.org/t/unset-environment-variable/9025/5

Is there any concern about adding only Unix.unsetenv?

As anecdotal evidence, recently I had to write some ad-hoc binding of unsetenv for unit tests that need to manipulate environment variables.