I agree the use of _BESClient_AllowCustomRepoDownloads would be preferred, but I can see that there are some complications to consider on it.
The AllowCustomRepoDownloads option was originally envisioned for things like Java - where every Java binary had a different filename, they could all live side-by-side in the repo folder and every version’s fixlet could find the file it needed. And, they really did need to be manually downloaded, per Oracle licensing and a captive download site.
Every version of Chrome has an identical download URL - Google replaces the binary in-place. Which means the file name beneath the path references at _BESClient_AllowCustomRepoDownloads would also have to be in sync with whichever version of the Chrome fixlet you wish to deploy.
As far as the BES server is concerned, there’s nothing special about the MANUAL_BES_CACHING_REQUIRED string, it’s just there to help out us humans to easily spot the manual download is necessary. For every download the server always checks whether the file is already present at bfmirror/downloads/sha1 before downloading it from the Internet - that’s how the AirgapTool and BESDownloadCacher allow disconnected BigFix servers to work without Internet access.
I’m not sure what the ideal solution / workaround would be for this special-case where the version changes frequently, and every version uses the same download URL.