cmd/go: TestScript/goroot_executable failures with "package … is not in GOROOT" on darwin-amd64-10_14 builder

[bcmills]

#!watchflakes
post <- builder == "darwin-amd64-10_14" && `package .* is not in GOROOT`

2021-01-06T15:02:50-d213170/darwin-amd64-10_14
2021-01-05T23:31:36-3e1e13c/darwin-amd64-10_14
2020-10-27T06:32:35-1095dd6/darwin-amd64-10_14
2020-10-23T19:36:38-3931cc1/darwin-amd64-10_14

--- FAIL: TestScript (0.04s)
    --- FAIL: TestScript/goroot_executable (6.33s)
        script_test.go:213: 
            # In this test, we are specifically checking the logic for deriving
            # the value of GOROOT from runtime.GOROOT.
            # GOROOT_FINAL changes the default behavior of runtime.GOROOT,
            # and will thus cause the test to fail if it is set when our
            # new cmd/go is built. (5.483s)
            # Relocated Executable
            # cp $TESTGOROOT/bin/go$GOEXE $WORK/new/bin/go$GOEXE (0.043s)
            # Relocated Tree:
            # If the binary is sitting in a bin dir next to ../pkg/tool, that counts as a GOROOT,
            # so it should find the new tree. (0.059s)
            # Symlinked Executable:
            # With a symlink into go tree, we should still find the go tree. (0.111s)
            # Runtime GOROOT:
            # Binaries built in the new tree should report the
            # new tree when they call runtime.GOROOT. (0.624s)
            > symlink $WORK/new/src -> $TESTGOROOT/src
            > symlink $WORK/new/pkg -> $TESTGOROOT/pkg
            > exec $WORK/new/bin/go$GOEXE run check_runtime_goroot.go $WORK/new
            [stderr]
            ../../new/src/path/filepath/match.go:12:2: package strings is not in GOROOT ($WORK/new/src/strings)
            [exit status 1]
            FAIL: testdata/script/goroot_executable.txt:44: unexpected command failure
            
FAIL
FAIL	cmd/go	139.662s

Given the other kernel/filesystem issues on macOS 10.14 (#33041, #37605, #33776) and the lack of similar failures on other builders, I'm inclined to suspect that this is a 10.14-specific kernel issue.

CC @jayconrod @matloob @golang/release

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)