Yeah, it might work, but there be dragons as it is completely 
untested setup. Please let us know what you find out!

Do you specifically mean the "two kresd instances with non-identical
configurations (aim to) share a single cache" is dangerous/not supported?
In that case we would simply have have distinct caches - which is a bit
unfortunate but we prefer less dragons.
After all we will first see if there is actual demand for that use-case.

I believe it's safe if you're careful with configuration differences, i.e. know what sharing cache means.  Still, it's true that the possibility is mainly a by-product of the design and not tested in any way.  There are currently only RRs and packets along with some meta-data, but people tend not to realize all consequences, e.g. around aggressively generated answers from NSEC(3) records.  Changes like forwarding to different resolvers (or iterating) shouldn't be a problem, assuming all of the targets serve the "original" (unfiltered/unmodified) DNS tree.

Thanks for elaborating on this, we will keep nginx then.
Does kresd aim to support x-forwarded-for or similar HTTP headers
to expose the client IP from the HTTP reverse proxy to kresd?

Yes, I think so; I had thought about that already.  I expect the support for x-forwarded-for would be easy to add and likely to be useful.  We only just released the first version with DoH, and on the whole DoH hasn't seen that much real-life use yet.