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
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.