Unfortunately I think this does run up against at least one --no-binary use case we do know about, which is that some packages cannot be built as wheels. My understanding is that --no-binary is doing double duty - it’s saying “don’t use a wheel if it exists” but it’s also saying “don’t build a wheel as part of the install procedure”.
If you have build dependencies that cannot be built as wheels, having the --no-binary flag not apply to build dependencies would break your build. If the proposal is that the :all: selector simply doesn’t match build dependencies, but any explicitly-listed selections do, then I’m much more sympathetic. You could add another selector like --no-binary :all-build:, but I think it would be a damp squib, since it would be broken for all packages that ultimately depend on setuptools, which at the moment is all packages.
Presumably this is solved by the fact that you immediately recurse into a state where you do know the name of the project you are building, because you’re trying to satisfy a build dependency. If I do pip install . for setuptools and it tries to install setuptools from source, it may not recognize that the name is the same, but on the next recursion it will notice the name is the same.
That said, thinking about it more, we may not be able to get away with the “only have to break cycles of length 1” problem, at least not at the moment. I notice that if I add setuptools to setuptools’s build-system.requires, it fails building wheel, not due to some infinite regress or in building setuptools, because both setuptools and wheel depend on ['setuptools', 'wheel'] (wheel depends on these implicitly because it has no pyproject.toml). I think there are pretty simple solutions to this, but unless I’m way off the mark, it’s not as simple as I thought.
One more thing to note is that there’s a difference between PEP 517 saying you must resolve source build dependency cycles with wheels and pip deciding to resolve source build dependency cycles with wheels. If we specify it in PEP 517, all compliant frontends must do it that way. If we leave PEP 517 silent on the matter, frontends can do whatever they want (including not supporting non-wheel installs of build dependencies), though to be fair everyone’s going to optimize for however pip does it, so it will just become a de facto part of the standard at that point.