Our farm's network outage (or rather great lagginess - not outright refusal of connections) caused many empty `git ls-remote` responses during a Poll SCM and/or Branch Indexing scan, which (when seen as a string) do differ from the latest known/built hashes, and so cause rebuild of our world on our CI farm due to "SCM Change":
As discussed on IRC with Mark Waite, posting the issue here to not get it lost.
The likely course of action is to add a (global? later per-org etc.?) toggle whether to treat the empty-strings, or perhaps anything that is techically not a valid commit hash (strictly or up 32 hex chars?), or any codepath that already leads to logging "Couldn't get remote head revision", as an SCM Change or not.
This toggle would default to current behavior for least surprise (people can prefer and may be used to being on the safe side of rebuilding latest seen code, even if it means doing so several times sometimes) and to avoid new codepaths and interactions that might introduce breakage, but particular deployments can then flip it to not rebuild world (nor record the invalid last-seen commit) due to network hiccups like this, and have such skipping mentioned in their scan-log.