This patch suppresses the deprecation errors at each site, but there might be a simpler workaround in the same spirit: change the error_reporting calls (of which there are only a handful) to exclude E_DEPRECATED. That would risk masking any other deprecations (probably fine in production, but not in development), whereas this patch risks hiding any non-deprecation errors at these locations.

Although there's merit to the "zero, one, infinity" rule, it might not be the best option here. If something goes wrong and $err happens to always be falsy, this will end up in an infinite loop instead of giving a clear error message. There is probably a reasonable finite value (that's greater than 4) which can be chosen as the limit to the number of attempts.

There are some projects listed on the Phabricator Community Resources page. Would all of those be eligible for hosting here, or would there be some criteria to limit the number of external projects?

But why would we need to explicitly keep them? They already exist upstream...

My suspicion, though I hadn't thought through it much, is that it might be useful during migration periods where someone has the repository checked out and there's are clear linear branches of the phabricator development vs. phorge development.