"multiple sets" indeed.

The famous book Code Complete, which I just started on, talks about scaling software, and mentions that we now build software systems as economically large as building a highrise building.

On projects of THAT size, some project planning tools will spit out an estimate that you will need 59 different TYPES of documentation.

And they are right.

As things get bigger, you are going to need more and more TYPES of document. But just go with it... as long as it is accurate, it doesn't really matter how much you have.

Each type of documentation is going to have it's own issues.

With API POD docs, I find I now religiously document the return values for every single method.

For the main body, I go for elegant SYNOPSISs without too much confusing details, and that I wouldn't mind seeing in real code (because some annoyingly large percentage of people will just cut and paste your SYNOPSIS and modify it to suit their needs)

If I need diagrams, I just add a doc section. I find myself just piling files into it that I think will be useful, from visio diagrams to the "documentation" of XMLSpy to whatever I think might be useful later.

Even on small client projects, you'll be looking at 5-10 different types of documentation. Just remember to try and deal with them individually. What is the best way to write user docs, given they are stupid. Screencasts? Text Manuals? PDF Manuals?

What is the best way to write internal comments... API docs, etc etc.

You should be able to codify some sort of best practises for the different types of docs one at a time at your company with a bit of experience.