Fair point, but this post title should read "donutloop/mux – A lightweight, fast HTTP request router for Go", then :)

This. It's actually more idiomatic to use the same name, then you can often just sub out one library for another without any hassle.

Unless they have the same functions, variables, structs, etc., sharing the same name really doesn't provide much in terms of hassle-free substitution.

What? No! There's no indication at all these two libraries are compatible - why would you want two completely disparate projects to give some indication they support the same interface?

Because many of the base infrastructure libraries are compatible as long as they used interfaces (grumble grumble os.File). I would be very surprised if this doesn't implement net/http/ServeHTTP

It doesn't matter what it's named though, you can always alias the import.

If it was "github.com/foo/poppycock" I could just write import mux "github.com/foo/poppycock" and use it as mux.

Import name similarity is a terrible argument for picking a name.

There are cases where it makes sense, like https://github.com/pkg/errors which is meant to be a drop-in replacement for the stdlib `errors` package containing a superset of its functionality.

Then refer to the library by a name, and tell people to import $NAME/mux. You can also name the imports if people want.