I don't understand the purported use case for this. Relying on packages not being in the cache to prevent an issue is strange, since everything is listed in the output. I also don't understand why a dependency being pulled in recursively would be a bug, that's just how package management works.

Everything might be listed in the output, but when building everything is automatic, since --no-confirm is used. So I'd have to quickly kill things while pacman was already downloading something I don't want to be downloaded.

And I'm not saying a dependency being pulled would be a bug, just something that I don't want happening here. (Or, a bug on my end only.) E.g. if the package to be built depends on gtk3 (or has a dependency that does), I don't want pacman to end up downloading/installing it, I'd want to have another package, providing gtk3 but with maybe a different set of dependencies as the official gtk3 package, to be installed instead.

Using --private-network, in case e.g. I missed the gtk3 dependency and failed to install my gtk3-jjk package in the chroot, I simply get pacman erroring out as it failed to download the gtk3 package. Everything is fast, clear, obvious. (This also happens without any flag, when building on a computer with no internet.)

Without the flag, either I see it as it is being downloaded and I get a chance to kill pacman and fix things; or I don't and it's only afterwards, after the whole package was successfully built in the chroot, that I need to go over things & realize what happened and need to start everything all over again.

Your goal and your proposed fix don't really seem related. If all you want to do is prevent the network from being functional, then bind mount an empty resolv.conf into the chroot. You can already do this with the existing flags.

Well, I'm not sure why you say they don't seem related, in fact I originally thought I'd have to configure something in the chroot, only to find, as I was reading some man pages, the --private-network option of systemd-nspawn which seems (to me) to do exactly what I want/need. That's why I decided to simply use it.

(Also, I quickly just tried bind mounting an empty resolv.conf and the network remained functional in the container.)

This patch doesn't even achieve the stated goals, because the existence of network connectivity has nothing to do with whether or not the "wrong" packages already exist in the cache. It also seems like a highly-specific use case that only you would ever need, which is an argument for solving it another way.

Also, if you want to build packages against foo-jjk instead of foo, the best way to do this is via makedepends+=('foo-jjk').

...

OTOH if makepkg supported a --confirm flag to negate a previous --noconfirm flag, you'd have the option of manually approving things.

So I really feel this is an xyproblem.