I've since verified the same behavior exists on Windows 11 amd64.

Thanks for reporting. I can reproduce a similar issue in windows/amd64 with go1.20 using PowerShell too:

PS C:\Users\qmuntaldiaz\code\gotest> go run .
2023/08/11 16:20:09 os.Environ()[0] = "=::=::\\"
...

Found this excellent article from Raymond Chen, titled What are these strange =C: environment variables?: https://devblogs.microsoft.com/oldnewthing/20100506-00/?p=14133.

TLDR: Go is not inventing nor misprocessing environment variables, =C:=C: and friends are returned by the OS.

We could filter out variables starting with =, but I'm not sure it worth doing, someone could be expecting them. Quoting Raymon:

What should you do about these variables, then?

Nothing. Just let them be and do their jobs. I’m just mentioning them here so you won’t freak out when you see them.

@alexbrainman

I don't mind having them but I think there are some things that ought to be done about os.Clearenv and os.Setenv, as one cannot set them or clear and restore them.

Perhaps we should have a way to snapshot and restore environment, including weird things like that, reliably, without having to do it through the key=value interface?

Thinking about this some more and looking at

If that is too tricky then perhaps we could have a comment on os.Clearenv, that one cannot round-trip with os.Clearenv and os.Setenv to get the same environment that one had before, on some platforms, so that os.Clearenv should be used carefully - with a link to the article referenced in the Go source tree.

See previously:

• os: Environ doc comment does not describe keys containing "=" #49886
• os/exec: Cmd fails to enforce that Env entries are of the documented "key=value" form #52436

Note in particular that the deduplication logic for os/exec.Cmd was changed to handle these keys more correctly in https://go.dev/cl/401339.

I think there are some things that ought to be done about os.Clearenv and os.Setenv, as one cannot set them or clear and restore them.

Could you give some more detail on that?

The test I added in https://go.dev/cl/367850 does attempt to verify that os.Setenv works for those keys (or at least does not error out for them), and it looks like Clearenv is handling them correctly to.

@bcmills apologies, I misunderstood how to work with environment variables with a leading-=.

For anyone in the future looking at this, the entry is still ought to be a key=value pair, just that the key has a leading equals sign.

With this clarification all the stdlib functions work correctly:

package main

import (
	"log"
	"os"
	"strings"
)

func main() {
	before := os.Environ()
	os.Clearenv()
	for _, ent := range before {
		idx := strings.IndexByte(ent, '=')
		bias := 0
		if idx == 0 {
			idx = strings.IndexByte(ent[1:], '=')
			bias = 1 // ----------------^
		}
		if idx < 0 {
			log.Fatalf("Environment entry %q is missing an =", ent)
		}
		idx += bias
		k, v := ent[:idx], ent[idx+1:]
		log.Printf("Setting environment variable %q to %q", k, v)
		if err := os.Setenv(k, v); err != nil {
			log.Fatalf("Cannot set environment variable %q to %q: %v", k, v, err)
		}
	}
	after := os.Environ()
	if len(before) != len(after) {
		log.Fatalf("Environment size differs %d != %d", len(before), len(after))
	}
	for i := range before {
		if before[i] != after[i] {
			log.Fatalf("Environment entry %d differs: %q != %q", i, before[i], after[i])
		}
	}
}

This leaves me with only one suggestion, perhaps there ought to be an os.SplitEnv that knows how to correctly split a key=value pair with leading =

One small remark about the test added in https://go-review.googlesource.com/c/go/+/367850 -- I think it handles missing, non-leading = incorrectly and would fail to report an error on environment with an entry like =foo, because it unconditionally adds one to the index once the leading = was skipped over.

For reference, my implementation of splitEnv: https://gitlab.com/zygoon/go-cmdr/-/merge_requests/63/diffs

perhaps there ought to be an os.SplitEnv that knows how to correctly split a key=value pair with leading =.

That sounds reasonable to me. Want to file a separate proposal?

Duplicate of #49886