I'm coming in a little hot and contrarian. I've been working with the Go JSON library for well over a decade at this point, since before Go 1.0, and I think v1 is basically fine.

I have two complaints. Its decoder is a little slow, PHP's decoder blows it out of the water. I also wish there was an easy "catch all" map you could add to a struct for items you didn't define but were passed.

None of the other things it "solves" have ever been a problem for me - and the "solution" here is a drastically more complicated API.

I frankly feel like doing a v2 is silly. Most of the things people want could be resolved with struct tags varying the behavior of the existing system while maintaining backwards compatibility.

My thoughts are basically as follows

The struct/slice merge issue? I don't think you should be decoding into a dirty struct or slice to begin with. Just declare it unsupported, undefined behavior and move on.

Durations as strings? Why? That's just gross.

Case sensitivity by default? Meh. Just add a case sensitivity struct tag. Easy to fix in v1

Partial decoding? This seems so niche it should just be a third party libraries job.

Basically everything could've been done in a backwards compatible way. I feel like Rob Pike would not be a fan of this at all, and it feels very un-Go.

It goes against Go's whole worse is better angle.

Without any major changes, struct tags cannot solve the majority of the problems, because they do not propagate. The v1 MarshalJSON/UnmarshalJSON interfaces are too simplistic. At the very least, an alternative pair of interfaces should exist, which take options/flags/tags/whatever in the parameters. However, I agree this doesn't need to be in an entirely new package. It's not even hard to favor one interface over another:

  switch ifc := val.(type) {
    case MarshalJSONV2: // new interface, always used if present
    case MarshalJSON:   // old interface, fallback
    default:            // type isn't self-marshaling
  }

I like the "does the problem justify the solution's complexity" question. The deserialization performance improvement seems like an actually important benefit though.

Also https://antonz.org/go-json-v2/#marshalwrite-and-unmarshalrea... not completely sure but maybe combining

dec := json.NewDecoder(in)

dec.Decode(&bob)

to just

json.UnmarshalRead(in, &bob)

is nicer...mostly the performance benefit though

> Durations as strings? Why? That's just gross

> It goes against Go's whole worse is better angle

One could almost say that durations as strings is...worse.

lol