This is a two part affair... both broken by 5c1b83d9b1e8c

The first issue is that after saying no to a replacement, pacman will iterate through the remainder of the current tree being analyzed and claim that every package from the proposed replacement onwards is a valid replacement for the initial candidate:

:: Starting full system upgrade...
:: Replace util-linux-git with core/util-linux? [Y/n] n
:: Replace util-linux-git with core/vi? [Y/n] n
:: Replace util-linux-git with core/vpnc? [Y/n] n
:: Replace util-linux-git with core/wget? [Y/n] n
:: Replace util-linux-git with core/which? [Y/n] n
:: Replace util-linux-git with core/wireless-regdb? [Y/n] n
:: Replace util-linux-git with core/wireless_tools? [Y/n] n
:: Replace util-linux-git with core/wpa_actiond? [Y/n] n
:: Replace util-linux-git with core/wpa_supplicant? [Y/n] n
:: Replace util-linux-git with core/xfsprogs? [Y/n] n
:: Replace util-linux-git with core/xinetd? [Y/n] n
:: Replace util-linux-git with core/xz? [Y/n] n
:: Replace util-linux-git with core/zd1211-firmware? [Y/n] n
:: Replace util-linux-git with core/zlib? [Y/n] n
there is nothing to do

The fix for this is just to reset "found" after the user says no to replacing util-linux-git with core/util-linux, such as:

https://github.com/falconindy/pacman/commit/4db73ca41d829b9f3b5727b545c14af49802b778

But that still leaves us in an awkward position that pacman still wants to replace util-linux-git with core/util-linux (as both provide util-linux-ng, triggering the replacement):

:: Starting full system upgrade...
:: Replace util-linux-git with core/util-linux? [Y/n] n
there is nothing to do

The problem is that we're looking at providers now via the depcmp functions, and not just a 1:1 match of replacements to installed packages. This makes for an awkward experience with some VCS packages. I'm not entirely sure what the fix here is, though.