I didn't know that was a problem.. quite demanding from someone who says it's ok to require intimate knowledge of the distro's file layout.

Sigh. If you didn't realize that this whole discussion was about distros where files meant only for build/test should not escape the distro, then what did you think it was about? The second paragraph of the OP says "When you have libraries that are used by the build/test process but not part of the runtime code..."

There is nothing to discuss in the simple case where everything needed to build/test also gets installed. For that scenario M:M and M:B do indeed both work the same way: just put everything in "distroRoot/lib". The conventions and capabilities of M:M and M:B only begin to diverge once you introduce modules needed for build/test but not runtime.

I don't think a downloader should need to have intimate knowledge of a distro anymore than you do, which is exactly why I want a clean, portable way to put paths into @INC for them when there are reasons why Perl modules can't go into /lib (i.e. they are needed for build/test but should not leave the distro.)

Just to be clear, I'll make myself even more demanding and add some additional conditions to the requirements you already consider too demanding:

propose a solution that uses ExtUtils::MakeMaker to run make file commands, doesn't interfere with M:B, is 100% portable, respects separation of concerns (no confusing operational code with the configuration needs of a specific environment), allows a user to verbosely run individual tests without knowing what libraries internal to the distro are needed to run the tests, and ensures that files meant for build/test but not runtime never leave the distro.

But it doesn't change a thing. ./Build supports all of the above (see the --test_files, verbose=1 command line options discussed in Module::Build). It is all right there in the docs - no source code diving needed.

Heck, it will even let you run ./Build from any directory in the system. No cd'ing needed. So if you really want to run t/the-only-test-I-care-about.t from your home directory rather than distro root, just type $distrodir/Build test --test_files=t/the-only-test-I-care-about.t verbose=1. Your concerns that M:B would make you do something yucky like know the layout of the distro or cd'ing to run a single test are unfounded.

If it is too much to ask a makefile backed by M:M to also do all of the above, I'd tend to say that the problem lies with M:M and not with the wishlist. If it is not too much, then present your solution. That wishlist contains nothing but the expectation that M:M allow distro developers to conform to best practice (portability, separation of concerns, etc). If you consider that unreasonable, we will simply have to agree to disagree. I'll read what you write, but I have nothing further to say.

To me, striving to support best practice and being willing to point out when software fails to support it, is absolutely necessary for the long term health of the Perl ecosystem. Lowering expectations to match the capabilities of a beloved tool (M:M) is counter-productive.