>  Instead of recursive removal of mismatched packages, make a list of
  >  what needs removing, and what will be added, tsort it, and 'pkg_add
  >  -u' or 'make replace' down the list.  This should result in the same
  >  end state, but have fewer missing packages during the process.  But,
  >  packages may fail in more interesting ways, rather than 'command not
  >  found'.

	  How would that hand the case of pkgA and pkgB both needing
	  update and both being dependencies of firefox?

pkgA pkgB and firefox would all be in the 'need (possibly recursive)
removal', and hence in the tsort, and then one would

  pkg_add -u pkgA-new
  pkg_add -u pkgB-new
  pkg_add -u firefox-new

so if A or B changed shlib versions or other interfaces, firefox would
be broken for a bit, but if not the window would be small.

	 This would be the fun :) Would a straight variation of
	 -g which only lists the top level packages be fine?

I think I'd still want more :-), but that would be a huge help.
Using sort/comm/etc. could get me the 'packages not in other list'
part.  I expect to do some hand editing, and my main pkg_chk files
have comments about why packages are needed.  So ending up with a list
of packages that are top-level in the current system but that aren't
listed in another file probably fully implements what I would like.

I really appreciate that you made pkg_chk work without pkgsrc present
- that makes it very useful (vs. not applicable) in my testbed
environment, where I don't have any sources on most of 21 notebooks,
and mostly use a single build machine.