Not that I think it makes much difference but I use tunnel mode for my
  ipsec not transport mode.

I suspect the IPsec part is not relevant, unless the loss of
connectivity happens due to IKE rekeying glitches.  But I would be
very surprised if tunnel vs transport mattered.  For the record, I use
transport from each machine to the server.

  have you tried setting the connection to strong?

I think so, but this was a transition to disconnected, not write
disconnected, so I don't see how that would help.
I can try it though.

  I use CVS on my coda setup a lot, mind you, I do not do cvs operations
  on the laptop when I am in connected mode (not for any Coda reason, it
  is just the way my network topology is...), if I am at home then the
  cvs operations happen on the server so I may be missing something due
  to the good connection between server and client.  If I do do cvs
  operations on the laptop then Coda is always in disconnected mode,
  again not for any Coda reason, just the way my network is.

I meant to say RCS, not CVS - rcs in coda is much more stressful since
the ,v files get modified, whereas in CVS they are on the CVS server.
(I would think it pointless and perhaps insane to keep cvs server bits
in coda; I prohibit cvs-over-nfs in my workgroup to make sure the cvs
server process and files are on the same machine and locking works
etc.  Plus, this means that the cvs conflict mechanisms are used -
doing repair merges on ,v files sounds highly ugly, especially for big
commits.  But I suppose there is an availability argument to be made,
but IMHO coda is not reliable enough to beat a single machine, esp
with RAID.)

  Yes, I have seen this sometimes.  The repair just wedges or returns an
  error and after that the client seems to be a quivering wreck
  requiring an init to get it right.

OK - so I am not the only one seeing this bug.

  when I hit problems my first move is to grab the tar file in
  /usr/coda/spool/<uid> so I can keep most of my modifications, at least
  the ones that were done more than 10 minutes ago.

I should have done this; I had thought that the server had not got the
updates, and I'd be able to just retype the 1-line change I was trying
to make.  A secondary brokenness (not sure where) was that the server
ended up in an inconsistent state (0-length ,v file) that RCS tries to
avoid by using rename(2).