I just had a realization: now that CachingResultsSource operates on the level of check results (serialized), not on one big wbcheckconstraints response array, there’s no reason why we shouldn’t be able to store the results of Special:ConstraintReport checks in the cache, even though we don’t want to use the cache for the special page. In other words – the special page acts like a wbcheckconstraints request with status=*, and while we don’t use the cache for such requests (because we don’t want to store loads of compliance/not-in-scope/… results in the cache), following T189593 we’ll still store the results of those requests in the cache. There’s no reason why we couldn’t do the same for the special page as well, I think.

In technical terms, I assume this means injecting a ResultsSource instead of a DelegatingConstraintsChecker into the special page, and then using a CachingResultsSource as the implementation in newFromGlobalState(). And since the API and the special page should use the same instantiation for this, I guess the ResultsSource construction (including the config check whether we want to do caching at all or not) should move into the ConstraintReportFactory.

In theory, this should improve the cache hit rate. But in practice, almost nobody uses the special page (at least not on Wikidata), so marking as low priority for now.