It seems to me that testing.M.Cleanup can be implemented simply using defer. This isn't true for testing.T.Cleanup, because of parallel subtests, which can continue to run after the test function completes. So I don't see a strong argument for adding testing.M.Cleanup.

It sounds like we don't need to worry about an M.Cleanup until/unless we have M.Fatal etc.
And I don't know why we would have M.Fatal - is that a separate proposal?
M is intentionally low-level. It's not supposed to be something with a rich API.

It's certainly easy to add a sentence or two to testing.M.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

Change https://golang.org/cl/334649 mentions this issue: testing: clarify in docs that TestMain is advanced

No change in consensus, so declined.
— rsc for the proposal review group

Reviving an old issue, the use case here is that deferred functions that are called in TestMain do not run if there's a panic in m.Run, even if there's a deferred recover on the stack in TestMain. Any processes started in TestMain don't get cleaned up when the test exits in this case.

Adding my hat to this. The documentation on testing.M is a bit confusing and contradictory to being able to cleanup after functions. The main example is that m.Run returns an exit code that is meant to be used in os.Exit.

It even says so in the documentation

However, were you to actually use os.Exit, it would bypass any defer statements you made in order to cleanup.

The best way I found to get around this was to only call os.Exit if the code was not a successful exit (i.e. not 0). But that's a bit wonky IMO. The documentation should probably be a bit more clear about that.

retCode := m.Run()

if retCode != 0 {
  os.Exit(retCode)
}