Believe it or not, I tried the 'zone transfer via dig' route,
scheduling via cron :-)

6 5 * * *      dig @X.X.X.X -y hmac-sha256:ioc2rpz.net-foo doh.ioc2rpz
AXFR > /etc/knot-resolver/doh.ioc2rpz

The files produced by dig don't follow the masterfile format, however,
so neither kresd nor named would load them without modification.

YMMV with kdig; haven't tried it as yet.

That's surprising me.  I certainly did succeed in the past with kdig and knot-resolver with some zones (relatively simple cases, no authentication).

Given current constraints, I found that it's more elegant to take a
zone transfer using an authoritative server (speaking of which, I must
try the Knot one), which can then also better keep the zone fresh.
Kresd's excellent watch functionality for RPZs makes this possible.

Sure, I do consider using auth servers among the best approaches here (even though it's not trivial to set up all).

For the RPZ stack logic to make sense in a top-down approach, guessing
that we should make the decision / exist the stack on the first match,
so if passthru matches in tier 1 and there's an NXDOMAIN match in tier
2, the traffic gets passed.

I wasn't too keen on adding (many) tiers for efficiency reasons.  So in the currently released 6.x versions all local-data rules (+defaults) get merged into a single tier, so a single search can search it all.

The issue is that kresd does not currently recognise "rpz-passthru" in
the RPZ zone files, according to logged errors.

Yes.  We do have this feature inside one public branch (jezek-test, which gets used in a particular project now).  The current semantics in there is that if the QNAME in a client's request falls into a subtree of any names in the allow-list (expressed by rpz-passthru), this whole request's processing skips any blocking rules.  It's a compromise, nothing perfect, and it's unfortunately also far from the rpz-passthru definition in the RPZ draft.

--Vladimir