We also have JSON Merge Patch (https://www.rfc-editor.org/rfc/rfc7396), and both have very little adoption (judging by the available libraries & integrations)

I haven't used any of these yet, I've been waiting for one to obviously "win " and gain some support, but have definitely felt the pain.

Use case: Sending a Kafka message to add or remove a value from an array field without having to know the rest of the array

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…

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.

Same, works fine.

TerminusDB person here: we were using the API internally for our immutable collaboration database service [1] so we thought we'd make it available for others to use. We think it is better than the one derived from the RFC and built specifically for collaboration, but you can be the judge of that! In any case - choice is good, right?

[1] https://terminusdb.com/

We use JSON-patch/diff internally for our rebase operation. We looked at implementing it on rfc6902 but it turned out to be awkward because of the path descriptions, and insufficiently rich for the kinds of patches that we needed. We could have extended rfc6902 but then we'd be in the embrace / extend / destroy pattern no?

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.