Actually we are using json patch/json pointer extensively to limit data sent through network or update live data on a client(its embedded world). If user is changing single parameter on a client we sent just json patch as defined in RFC(including arrays modifications). Libraries are mature and simple to use(on client, on server we are using C++ so I suppose its a in house solution), thats why it's hard for me to understand why we need another solution for the same problem. Having said that I haven't used them in Kafka world.

For a(n anec)datapoint, I'm using JSON Patch in a production application.

Kubernetes supports both JSON patch and merge patch, and it has been a continuous source of amazement to me (in the “that’s a bloody giant hole in the ground” sense) of how hard actually calculating, representing, and developing durable intuition about finding differences between and merging JSON-like trees (empty lists, null vs empty, representing insertion vs deletion, lists with primary keyed members, list uniqueness, field ordering, duplicate fields, number equivalence, etc).

Add in defending against pathologically malformed patches - several vulnerabilities were discovered in the golang patch libraries Kube used - and one starts to develop a twitch whenever it is mentioned…

Yeah RFC6902 works best when you are only trying to create patches that are safe to apply to exactly the expected document.

You potentially need much more for some scenarios where you could be applying a patch to a previously modified document. It has some limited support for some common operations for these, but quite far from everything that could be useful. But it is also true that they needed to put the limit somewhere, and where they stopped is reasonable for a fair few scenarios, but certainly not every possible one.