CC @neild @bradfitz

Seems extremely racey.

If you need this functionality, why not just register a handler for / and then mux it yourself at runtime? I don't think this fits into the usecase for the standard serve mux, and it's very easy to write your own, so I would be opposed to any performance hit that would come from checking a lock at runtime.

The internal locking protects against basic races.
Creating a custom mux doesn't work well with libraries that use DefaultServeMux.

I don't think this is generally useful enough to warrant adding, and I suspect that a need to unregister handlers from a ServeMux points at a deeper design issue somewhere. For example, a library which is hardcoded to use http.DefaultServeMux depends on shared global state.

The design of ServeMux is intentionally order-independent, so that if you have things registered from init functions, it doesn't matter what order the init functions run. I'm very wary of adding something that would introduce order dependence in this API.

There are many other options if you need this functionality, of course, including writing a trivial custom mux.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

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

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