I've been thinking about the make(1) issue, and I should confess some personal biases. These aren't recommendations, just how I do things and perhaps why I don't run into the problems other people do.

1. I compile a lot of stuff. I typically don't use things like fink, binary packages, and whatnot. (I do use FreeBSD's /usr/ports and PPM though, put that's not very often).
2. I'm used to installing software, and some even non-Perl things have make(1) issues. I haven't kept a list, but some things request a particular make(1) variant. That's hasn't been a huge problem for me because I'm usually in the middle of something else that seems more of a problem at the time.
3. The problems with PREFIX sound more like problems with default installations of perl and its default configuration. I always compile and install my own perl.

Given that, I have these concerns

1. End users don't want to download more than they have to. Even if there was a Perl make(1), it's just one more thing for them to download. That's the biggest killer.
2. End users hate dependencies. On the surface they don't really care about code reuse and all that stuff the developers like. I've gone through most of my distributions and removed some modules end users complained about (like File::Find::Rule, which has a lot of dependencies).
3. I'd be much more likely to use Module::Build when it comes with Perl. Again, it's one less thing to download.
4. Re-inventing make(1) is probably not going to be as good as the make(1) implementations that already exist, and the Perl make(1) will have its own eccentricities.
5. Even with a perfect perl make(1), we still need to ensure it works on most of CPAN. That's not intractable, but not everyone is an early adopter and will want to wait to see how the new make(1) works out before they commit to it. That's the stumbling block for Module::Build right not. Solve that problem with Module::Build and you don't need the Perl make(1).