If it is intended as a tool to help port C++ code out of C++ into Go, it looks very useful.
If it is intended as a tool to help Go programmers, it has made a common, but regrettably very serious mistake, that programmers make when porting code: It has precisely copied the original API, despite the fact the original API is quite unidiomatic in the new language.
I don't want a package of all this stuff with the original API of C++; I want the same capabilities, but for them to be idiomatic in the new language. It is quite common that the resulting port will both be missing some things no longer necessary in the new language, but may also require things that weren't necessary in the host language.
As a nice little bite-sized example, consider some of the vector methods. PushBack takes a single element. It really ought to take a slice, probably via the "..." notation to make it a variable-argument function. That's idiomatic in Go. It is also idiomatic to offer that functionality and not worry too much about the fact it will be ever so slightly slower than not taking a slice. Go is generally fast, but if you care that much about speed to the n'th degree, you picked the wrong language. "Reserve" is in the original C++ API because C++ is not a garbage collected language. Go has the ability to specify sizes up front with slices, and that's generally enough. ShrinkToFit is generally again for a non-GC'd language... it's not useless in Go but again, if you're really paranoid about that being available you probably picked the wrong language.
Examples of this sort are pervasively shot throughout this API, from what a scan of it shows me.
A non-trivial amount of the complexity of the STL interface is related to manual memory management. In Go it results in APIs where even if you can't quite point at what the problem is, they're just generally overcomplicated in a GC language.
I expect something much simpler to implement, much simpler to use, and probably also faster to execute could be written if one wrote a list of the desirable capabilities down, and then ignored the C++ API and implemented the capabilities directly in idiomatic Go. Probably after crossing off a couple of things in the capabilities related to C++ being manually-memory-managed, and perhaps after adding some capabilities related to cheap threads being available, e.g., a parallel map operation that works across these data structures or something. Idiomatic, not just blindly copied.
(I comment on this because I do see this a lot. Since these sorts of libraries rarely take off it can be a fatal mistake made on a lot of effort.)