/cc @dvyukov for any theories.

This test requires physical parallelism, so my first bet would be on a problem in netbsd scheduler.

Perhaps execution trace will sched some light.

how can I run this specific test?

go test sync should work/

netbsd's nanosleep always schedules another process, even for really short sleeps. making it spin on really short sleeps fixes this

NetBSD nanosleep() always sleeps for at least 1 schedule slice when the specified time is under the schedule resolution. With default HZ value of 100 for i386 and amd64, it's always at least 10ms even when the specified time is smaller. I think other systems might work similar way.

@coypoop, or:

$ go test -v -run=TestWaitGroupMisuse2 sync

Or:

$ go test -v -run=TestWaitGroupMisuse2 -count=20 sync

It takes 45 seconds on AIX too, and never panics as it expects to:

https://build.golang.org/log/4521fa0230a42f6f3b70e8f108c3ab63d962d567

/cc @Helflym

I was already aware about this failure. But I didn't find anything relevant.
As the test says "The detection is opportunistic" and in some cases, I don't get a panic until iteration 500000... So a few other cases might not trigger it at all, but it's random.
Note that it also explains the slowness of this test. On a local Linux machine, almost all the panic occurs during the first 1000th iteration. On AIX builder, it's far more random, it can happen at the 10th one like at 100000th one...

Edit: as NetBSD, it might be related to AIX scheduler:

The suspension time may be longer than requested due to the scheduling of other activity by the system.

TestWaitGroupMisuse2 has mostly been passing on AIX as far as I can tell, but the failure mode from #22944 (comment) cropped up again in one aix-ppc64 builder run today (https://build.golang.org/log/a38f4c89dcb8e8b62b37ccefeae0de03dfcfecb5):

--- FAIL: TestWaitGroupMisuse2 (44.26s)
    waitgroup_test.go:133: Should panic
    waitgroup_test.go:96: Unexpected panic: <nil>
FAIL
FAIL	sync	44.880s