I use a similar style, but I also try to include a header section for the entire module that descibes what it does, why it was created and any other notes necessary. I usually include a $Id$ tag as well, just to make the version number quickly available.

Since I also use CVS for my source code control, I have also gotten in the habit of, at the very bottom of the POD, to create a HISTORY section and putting a $Log$ tag in there. It keeps the checkin history with the file, but doesn't clutter either the top of the file or r the POD with a lot.

I also have written code similar to yours to pull my sub headers out and marginally PODify them. Check out this node for one of my more interesting attempts ( the first toy ) at documenting the possible return values for a module.

mikfire