We want to give users the freedom to choose their preferred
configuration. By selecting an URL they can choose how we resolve
their queries recursively or non-recursively (so they can make their own
trade-off between small anonymity set size (= we handle recursion) and
who gets to see their query data - without their IP addr (bigger
anonymity set).
Sounds like we will need multiple kresd instances to cover this
use-case, which is fine. Multiple kresd instances with distinct configs
do not appear to be supported out of the box even though you ship a
multi-instance systemd service file, so a few systemd drop-in files
will be needed, which is also fine.

Yes, I expect now you'd best use multiple kresd instances... which means you'll also need some kind of http proxy anyway, assuming you want these to run on the same name/IP.  We consider running multiple instances with *different configs* quite a specific setup, so it isn't really considered in the systemd services shipped by default.  I expect you can still share the cache among these differently configured instances, at least based on the examples you wrote - I expect nothing changing the DNS data itself or trust anchors for validation... e.g. filtering actions via policy module aren't cached.

It is interesting to read that consistently in the kresd documentation
and here.

It's a warning.  We're not aware of "large deployments" of lua-http, contrary to e.g. nginx; that's some risk by itself, especially the consequences around less testing, less people maintaining the code, etc.

The files currently aren't watched for changes.  It will be easiest to
just restart the service, as cache is kept and occasional non-reply
tends to be handled well in DNS (and rotations tend to be rather
infrequent).

would be a nice to have kresd re-read files without needing a full
restart at some point.

I could imagine using a solution very similar to policy.RPZ, in future:
https://gitlab.labs.nic.cz/knot/knot-resolver/merge_requests/767

The reCAPTCHA is post-authentication and happened when trying to submit
an issue (so the question still stands).

I don't know... I haven't heard of this problem from anyone else yet, and I can't say I understand captcha stuff.  In the worst case, any communication channel is OK, especially for important issues.  Apart from this mailing-list, there's also non-public knot-resolver@labs.nic.cz and public chat on gitter.im.  In the extreme you can even encrypt e-mails by our personal PGP keys from https://www.knot-resolver.cz/download/

--Vladimir