|There's more than one way to do things|
I'm sorry to disagree. Everything you noted above is true, although I don't think the documentation is bad! Scarce maybe, but the articles and books that I've found did a good job of explaining the mechanics of a cookie and what the browsers don't do (but should). The one thing you forgot to mention is that when you set a cookie's host, you MUST access the host using the same name.
Ie: http://foo/ ne http://foo.bar.com/
I started using cookies with cookie-lib.pl which is a cookie library (doh!) inspired by cgi-lib.pl. That was a mistake! Many of the odd features that I blamed cookies and browsers for ended up being faulty implementations on the lib I was using. Once you fully understand the consequences of keeping user state (since HTTP still is a stateless protocol) through cookies, you can plan ahead, test, re-test and make sure that your applications run smooth.
Without cookies, my coding would soon become a living nightmare. cookies++ !!
BTW: You can always inspect your cookies by doing something in the lines of:
... and that would keep you from having to telnet to port 80 to retract your cookie info. (make sure to remove the comment line on production code, it looks odd)
# Trust no1!