> Four and a half design questions, and one odd-ball this time.
> 
> 5. static libraries (.a) distributed with a package don't need to 
> be installed when:
> (A) Never, they should always be installed
> (B) if unlikely to be used by other packages.
> (C) A or B at packager's discretion (criteria?)

Please just install them - then any NetBSD ports which cannot handle
dynamic libs will be fine. Also, there are fewer PLIST issues if you
just add the libfoo.so.major.minor and libfoo.a entries to the PLIST.

> 6. {INSTALL_MAN_DIR} should be used instead of ${MKDIR} when:
> (A) Creating ${PREFIX}/share/[docs|examples|man]/X
> (B) Always
> (C) Never

Personally, I never use it, because I've found that, after installing
a package which uses thses things, the modes and/or ownership of
directories which mtree checks are corrupt. YMMV...
 
> 7. It is acceptable to build X11 optional packages:
> (A) as a text-only package
> (B) as an X-11 only package
> (C) as multiple packages - i.e. Z (no X), Z-gtk, Z-tk, Z-xlib,
> which must CONFLICT, be committed at the same time, and have the same maintainer.
> (D) A and B

As in everything, take small steps, and you come unstuck less.
Firstly, I'd package up just the text-only bit. Then, if I found
I was wanting the X11 features, I'd add that, probably as a separate
package. Then the tk and gtk versions of the package. But get the thing
in-tree first in a working but minimalist version...
 
> 7b. A text-only package should:
> (A) Disable testing for graphics support.
> (B) Follow the normal install process for the tool.

Depends on 7 above.
 
> 8. Packages with options for supporting NetBSD features (i.e. IPV6)
> should be:
> (A) Never committed without support.
> (B) Committed with all the features the pkger can test.
> Someone else can fix other features later.
> (C) Prepared as far as possible, then referenced on tech-pkg, to find
> someone with the required hardware/software to complete the pkg.
> (D) B or C, judgement call based on pkg value without those features.

See diatribe above about walking before you can run. Then use your own
judgement and common sense, and others advice.
 
> 9. Creating a new pkgsrc category 'exper' to distribute new utilities
> proposed for future NetBSD releases, or test versions of utilities is:
> (A) The dumbest thing I've ever heard.
> (B) A useful thought.
> (C) Would be useful, but needs some guidelines (for inclusion) first.
> (D) B, but should be called...

I'd prefer not to have this - pkgsrc is (for better or worse, and
in a few cases, bizarrely) divided up based upon application type.
If the package doesn't fit one category, or fits more than one
equally well, ask for advice, but please don't just add another
generic category.

All of these questions, except the static libs one, are quite
general - it might be better if the problem was encountered first,
and then a solution was sought. No point in worrying about what
could happen before it does...

Regards,
Alistair