I don't have an answer for you, but I can imagine that most people will oppose this. Adding more complexity and long-term burden to the exposed API is a factor against exporting any name in std, and this particular piece of code is useless to almost every encoding/json user.

One exception would be someone who wants to write an encoding/json alternative, or someone who will fiddle with the internals such as yourself. In those cases, copying the code (while keeping the license) is usually the best overall option. It's not much code, either.

Since I didn't expect this to be quick, I made an quick implementation here: https://github.com/MOZGIII/go-jsontag
The thing is if golang's implementation will change, things will break on my side. But for near future it's an acceptable tradeoff. Also it works as sort of concept example.
Looking forward to more opinions on this topic.

By the way: my usecase is to build a description of a struct (that can also include other structs), with the information for each field about it's JSON name (dot-separated for nesting) and type (string/bool/etc).

@mvdan Just noticed you mention keeping the license. How do I do it right? It what's in my repo ok?

I agree with @mvdan. There is insufficient reason to expose this API, and it's easy to implement yourself. Implementing it yourself is not relying on encoding/json internals; it's simply handling the documented tag syntax in a way that is useful for you.

Closing the issue.