I just realised that my recent troubles with darcs may have been due to an error
code id-10-t (i.e. the problem was between the chair and the keyboard).  I had
messed up the darcs defaults syntax horribly, treating it as a sort of command
line than what it really is.

My issue was that I was writing them like this (BAD):
  send --edit-description --unified --sendmail-command="mstmp -t %<"

when in fact, I should have been writing them like this (GOOD):
  send edit-description
  send unified
  send sendmail-command="mstmp -t %<"

Argh, silly eric.  But maybe there is a chance to learn something here. The
reason I persisted in using the wrong syntax is that I was reinforced by darcs
seeming to work and do the right thing.  Particularly, if I entered
 send --edit-description --unified

darcs would appear to "work" (I would get a text editor before sending a patch).
  Of course, the patch would not be unified and I wouldn't notice, except for an
occasional remark by Tommy and me being generally confused.  The only thing that
got me to realise my blunder was noticing that for some reason
  send  --unified --edit-description
did NOT "work"

Because in both cases, darcs just ignored everything that came after the flag.

I would argue that a little bit more inflexibility on darcs's part could be good
for the luser.  Specifically, darcs could perhaps notice that --edit-description
and --unified do NOT accept arguments.  In this particular case, we will get an
error message and perhaps the user would be motivated to go look in that manual
again.  It won't solve all cases of user stupidity, but maybe it will help for
some common ones.

I second this wish.

This could make a nice slightly involved but not /too/ difficult starter task.

The following patch updated the status of issue691 to be resolved:

* Resolve issue691: distinguish between NoArg and ReqArg in defaults parser.