My quick not very well filtered reactions:

  I am uncomfortable about the coda security scheme being a roll-your-own
  thing.  I would want to look at Kerberos or DTLS.  I realize this is
  harder than it sounds.

  Whatever the next steps, IPv6 support is a big deal.

  I think it's critical to have a FUSE client so that coda can run
  anywhere that supports FUSE (the high-level interface, preferably).  I
  think it's perfectly ok if performance suffers a bit for this; working
  at 25% speed is 90% of the utility function for me, if not 95%.  And
  with modern CPUs the performane issues are not going to be a big deal;
  glusterfs on NetBSD (userspace FS, FUSE) is doing most of 1 Gb/s.  I
  think it's fine to have in-kernel implementations for those that
  really care about speed, but it seems the number of supported
  platforms has dwindled to Linux and NetBSD.

  The last big thing is to make conflict repair more robust, so that
  normal people rarely lose.  It's quite good already, but the last
  little bit is likely real work.

  Coda's behavior of doing a store when one does
  open-for-write/read/close is really awkward.  Arguably programs should
  not do that, but they do.   So I think it's necessary to not store
  then, even if that does result in calling in the read locks.
  Alternatively, open-for-write can be open-for-read, and upgraded on
  the first write, but I think just not storing is 90% of the win.


Note that I'm not using coda any more, despite having started in the 90s
and continued until 2015 some time.  The two reasons are having to run
IPsec to be comfortable with security and lack of portability.