The point you make is what I had in mind when I asked you to define
your terms. ;)

Having spent enough time exploring it myself, I must agree with you.
Some time ago, I though it might be worth it to do more work on
parallel builds.  However, once I started using it for bulk builds
instead of merely as a way to speed up building something I was
tinkering with, I realized that it's simply an unsound approach.  Even
discounting all of the PRs, my own personal list of MAKE_JOBS_SAFE
problems is massive!  In order to make any use of it, I have to write
way too many extra make rules--and that's not counting any obscure
failures I haven't accounted for.  One especially aggravating factor
is that the likelihood of failure increases geometrically the more
dependencies [and second-order dependencies ... etc] a package has.
Not only that, but, politically speaking, development of pkgsrc
features should take place within pkgsrc itself, not package
Makefiles.

BTW, is there a problem with pkgsrc locking these days?  If I use the
recommending lock types for wrkdir_locktype/pkgsrc_locktype, the
depends target fails instantaneously: because pkgtools/digest is in
BOOTSTRAP_DEPENDS, pkgsrc locks against itself when the build of
digest attemps to acquire the dependency lock. This could be fixed by
defining an additional lock type, but that seems somewhat like a
kludge to me.

--Blair