As there's continued misconceptions around that topic, here's another explanation:
First, "recursive make": make is a tool using commands from a "recipe" to process input files to output files in a process that can cascade. So it might produce file_b from file_a, which is needed to produce file_c later. To do that automatically, the input to make is a set of dependency rules (here, file_c "depends" on file_b) plus recipes which are short shell scripts required to do the actual processing.
As a consequence, make might fail when you forget to list a dependency. In the scenario above, if make attempts to create file_c before it created file_b, this will obviously fail. Even worse, make uses file timestamps to know which files are outdated and must be recreated. So, if you have a file_b from a previous build and file_c misses the dependency on it, it might be built using an older version of file_b.
Now, enter "recursive make": This is a widespread idiom for organizing a large source tree. Instead of depending on individual files from a subdirectory, you depend on a pseudo-target with a recipe that will just call make again inside this subdirectory, that has its own Makefile. This is somewhat simplified, but the main consequence is that you have to be very careful about the dependencies of these pseudo-targets, so the directories are built in the correct order (if you have errors there, they will typically manifest when building in parallel with make's -j option), and it will result in whole directories being built even if only a single file would be needed. But it has a few advantages as well: The whole structure is easier to grasp than with ONE huge Makefile (possibly using includes from subdirectories), and you have an easy way to just build one individual directory by calling make from in there. So, assuming you get the ordering correct, recursive make still has the one downside that it will build too much when only little parts changed. FreeBSD /usr/src uses recursive make and solves the problem of unnecessary build steps in a different way, see meta-mode.
The ports tree also uses recursive make. But this is an entirely different thing, as it doesn't build anything itself, but instead organizes builds of individual software packages, from downloading the distribution files to packaging the result of the builds. For the actual builds, the build systems provided by the upstream packages is used. So, there is just no alternative to recursive make for a thing like the ports tree. Furthermore, this has nothing to do with the handling of dependencies between ports. These are handled in a clever way by the make framework in /usr/ports/Mk, which uses special variables set in the Makefiles like e.g. BUILD_DEPENDS. And finally, you almost never use the recursive infrastructure of the ports tree, but instead build individual ports directly from within their directory.
Portmaster also doesn't use the recursive make infrastructure, but parses the special variables in the individual ports' Makefiles and handles these dependencies itself. So, it has nothing to do with "recursive make". Also, there's nothing wrong with Portmaster per se, it does work as intended.
Now, what's the problem with Portmaster? The same as with building ports manually from the ports tree. It's neither a problem with the ports tree OR with Portmaster itself, but with the build systems of some upstream software packages.
Many software packages have build-time configurations, so they can optionally require additional libraries for optional features. The build systems used offer means for configuration, e.g. with the widespread "GNU autotools", you will have a ./configure shellscript doing that. These configuration tools are meant to do two things: They let the user decide (e.g. with commandline flags) what optional features should be enabled, and they check whether the needed libraries for these features are actually available.
Now, due to either bugs or cluelessness of upstream authors, it can happen that some optional feature is automatically enabled if the build system finds the needed libraries on the system you build on. This is called an "automagic dependency" and should be avoided, but sometimes, upstream build systems fail to do so. It happens mostly when home-brewn build systems (e.g. with large hand-written Makefiles) are used. Say the port/package "frobnicate" has an option to enable feature BAR, which should cause it to link "libbar.so". What *could* happen is that you don't enable that option, so the package you install won't have a dependency on libbar, but the buildsystem would find that libbar.so on your system and link to it nevertheless. You will end up with an implicit dependency pkg knows nothing about, and once you remove "libbar" (pkg will have no objections, nothing depends on it!), your "frobnicate" is suddenly broken.
Tools like poudriere or synth solve this problem: They run each build in a clean environment with ONLY the packages installed that are actual and intended dependencies of the port to build. This is again a BIT simplified, but it's basically the main thing…
So, all of this has nothing to do with "recursive make", and Portmaster isn't "broken" either, it's just there are better and more reliable alternatives and you should look into using one of them to profit from it.
