The cURL man page describing the use of --cookie-jar is contradictory.
It starts off talking only about *writing* cookies, leaving the reader
confused as to when cookies are *read*:

manpg> -c, --cookie-jar <file name>
manpg>
manpg> Specify to which file you want curl to write all cookies after
manpg> a completed operation. Curl writes all cookies previously read
manpg> from a specified file as well as all cookies received from
manpg> remote server(s). If no cookies are known, no file will be
manpg> written. The file will be written using the Netscape cookie
manpg> file format. If you set the file name to a single dash, "-",
manpg> the cookies will be written to stdout.

As the reader wonders how/when cookies are read, the manpage continues
to say:

manpg> This command line option will activate the cookie engine that
manpg> makes curl record and use cookies.

Use of the term "cookie engine" implies to the user that some
fully-featured machinery is going to take care of all the cookie
handling, as a GUI browser does.  Then it says the engine will "record
/and use/ cookies".  "Using" a cookie implies /reading/ it.  But the
--cookie-jar option never causes cookies to be read, does it?

manpg> Another way to activate it is to use the -b, --cookie option.

Saying "another way to..." implies that the --cookie option is an
alternative to the --cookie-jar, but I've heard that the --cookie
option is generally used *in tandem* with the --cookie-jar.

Where can I find clear documentation on this topic, with working
examples?

Anonymous <nobody@remailer.paranoici.org> wrote in
news:14b1be85fa69d03170ae88170a6787cb@remailer.paranoici.org: 

> Where can I find clear documentation on this topic, with working
> examples?

I'd suggest you try the cURL mailing lists.
http://curl.haxx.se/mail/

How to use these mailing lists:
http://www.gnu.org/software/mailman/mailman-member/index.html

Here's a sample search:
<http://search.gmane.org/?
query=cookie+jar&author=&group=gmane.comp.web.curl.general&sort=relevan
ce&DEFAULTOP=and&xP=Zcooki&xFILTERS=Gcomp.web.curl.general---A>

> I'd suggest you try the cURL mailing lists.
> http://curl.haxx.se/mail/

The cURL mailing lists are broken as far as I'm concerned - but thanks
anyway.  Specifically, mixmaster messages sent to the address
curl-users@cool.haxx.se never get through.

I eventually got the answers I needed.  Maybe I'll document it for the
next person.

Jack Ryan <noreply@remailer.cpunk.us> wrote in
news:2f2e07061640e2d6ecf9e46b27cd4f57@remailer.cpunk.us: 

>> I'd suggest you try the cURL mailing lists.
>> http://curl.haxx.se/mail/
> 
> The cURL mailing lists are broken as far as I'm concerned - but
> thanks anyway.  Specifically, mixmaster messages sent to the
> address curl-users@cool.haxx.se never get through.
> 
> I eventually got the answers I needed.  Maybe I'll document it for
> the next person.

Glad you found your answers.  You do have to subscribe to a mailing 
list before you can post new questions, but I often have good luck just 
searching previous posts.

> You do have to subscribe to a mailing list before you can post new
> questions,

s/a (mailing) list/some \1 lists/

Only some mailing lists are overly controlled, imposing extra manual
human effort to become a member even just to post a one-off, or even
to reply to an existing thread.  Those walled-gardens and the inherent
shenanigans are not for me.  If I cannot simply post, then I just
walk.. can't be bothered with process and disclosure, then the
possibility of moderator deletions/alterations.

Hence why usenet is good.  The comp.infosystems.www.browsers.misc
newsgroup is apparently the most-fitting open forum for cURL
discussion.