> I presume by "top-level" you are referring to the NetBSD "src" tree.

No. This applies to any circumstance in which you want to specify an
alternative system make file directory by using `-m'.


>   When the command-line options -f or -p are used, they will take effect
>   regardless of whether they also appear in MAKEFLAGS. If they otherwise
>   appear in MAKEFLAGS, the result is undefined. The MAKEFLAGS variable will
>   be accessed from the environment before the makefile is read. At that
>   time, all of the options (except -f and -p) and command-line macros not
>   already included in MAKEFLAGS are added to the MAKEFLAGS macro. The
>   MAKEFLAGS macro will be passed into the environment as an environment
>   variable for all child processes. If the MAKEFLAGS macro is subsequently
>   set by the makefile, it replaces the MAKEFLAGS variable currently found in
>   the environment.
> 
> : 	This means that all invocations of make during makefile parsing
> : 	do not inherit the command-line options through the MAKEFLAGS
> : 	environment variable.
> 
> Like ${PRINTOBJDIR} et al?
> 
> As per POSIX, I believe these options should be made available bin MAKEFLAGS
> efore Makefile parsing begins, and thus available to != invocations.  If
> this isn't the case, it's a bug.

Well, it isn't the case. The MAKEFLAGS variable is not exported to child
processes until after makefile parsing has completed. So POSIX specifies
that all options except -f (and -p, which we don't have) should be exported
to all child processes.

But this does not make sense for all options currently accepted by our make(1).
I already made the case for -m and -r, and there are probably a lot more
which can be passed on without incident.  But consider the effects of
propagating -n, -N, -q and -V, especially on `!=' invocations. In all
likelihood, this will not DTRT.