[Lewisham]

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.

[nkozyra]

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

[1_2__3]

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?

[Lewisham]

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

[TheDong]

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.

[insertnickname]

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.

[jerf]

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