Thank you.
I've created trunk branch especially for merging this. I mostly agree with whole your changes but wanna do my best to add also tests and to check it prior to releasing.
Also I'm going to avoid using http-kit and cheshire - we have a lot of services where another libraries are used.

I've just copied your code into our codebase exactly for those reasons. I'm trying to avoid depending on cheshire, because most of the time we don't need its performance or fancy object mapping features, but it touches on the jacksonxml dependency hairball and that has already caused issues with Datomic Cloud.

httpkit I like in general, but I don't think this library needs to have a hard dependency on it.
you could just provide a function, which returns the httpkit compatible request map and let the consumers do the actual htttpkit.client/request call. "just data!" ftw! :)

btw, we are using https://github.com/oliyh/martian for most of our http client needs. it's very nice and pluggable. we have learnt a lot from it!

The same for me here - I'm fine with using http-kit in general, but...
seems there is only the way of splitting the library between J1.8 and J11.
J1.8 will still use http-kit which is pretty fine and mostly have no external deps and implemented mostly in native Java.
And then wrap (for JDK11's) java.net.http.HttpClient. as an internal client helper.

Regarding JSON I'm thinkng about using of pjson.core/write-str here. It is extremely fast and all its trade-off are in parcer.

Anyway. I've released intermediate version with yours patches and with some changes to allow testing. It will not to break existing usage at all for us and for external users. And thus the trunk is the right place for such experiment of eliminating these two.