Kerberos has existing mechanisms to find a (krb) realm for a given
host.  This can be viewed as finding a krb realm for a domain (dns
name, including hosts - I'm using domain in the general sense it is
used in the RFC).  Coda realms are domains as well, and this is more
or less enforced by using SRV records to list the auth2 server and the
master coda servers.  So, it seems straightforward and clean to me to
map the coda realm, interpreted as a domain, into a kerberos realm.
If the default rules don't work, then config entries or a krb dns
realm record is needed, just like if the KRB.REALM from a hostname
using the default rules doesn't get the right host/f.q.d.n_at_KRB.REALM
value.  I in fact used to do this (not for coda) for a foo.example.com
that was in the SUB.EXAMPLE.COM kerberos realm, as if it has been
foo.sub.example.com.

  Even not mentioning that Kerberos rules to translate DNS domain names
  to Kerberos realms have little ground to exist at all.
  There is nothing that binds a certain host to a certain Kerberos realm.

Well, it depends on the administrative setup.  I've usually seen
Kerberos realms aligned with domains, run under common administrative
control.

I think my real point is that while finding the krb realm for a given
domain (e.g. a hostname) is messy, auth2 isn't really all that
different.  (And we are talking auth2 for now, really, rather than
kerberos.)

I agree that if you want different services on a host to be in
different kerberos realms, that's much messier.  But that's an
existing kerberos problem, and again not coda specific.

It also might be complex to have coda servers in the same coda realm
in multiple krb realms.  But if we map on the coda realm name, that
problem is avoided by declaring that they all match.