Well, essentially it doesn't matter at all, just provide a principal
  per coda realm, call it xyz1 or abc123, it will work as well,
  no /something part is necessary either.

It does matter because the client code will have defaults built it
that choose the principal based on the coda realm, and probably the
kerberos realm of the auth2 server (from the SRV record).  Having
sensible defaults will greatly reduce configuration.

  In fact we cannot dictate what the principal shall be called - as it is
  a discretion of the Kerberos realm administrators, not Coda ones :)
  We can suggest, not more.

True, sort of, but having a standard approach that reduces
configuration is very helpful.  People can of course do whatever they
want (and who the kerberos people answer to is a local matter...).
Using the coda-realm as the instance, and 'codaauth2' (should match
IANA registration for the port, probably) fits in very well to how krb
weenies think things should be done.

  I do not see a real connection between the issues.
  It would be pretty different design (if any) and different Kerberos usage,
  why would we call principals the same?

They aren't that connected.  I was trying to argue that the design for
principals should be extensible to usage I hope to see later.