When parsoid bumps its output version, say from 2.7.0 to 2.8.0, the return value of Parsoid::defaultHTMLVersion() will have changed from when previous entries were entered into the parsercache.
A request for -H "Accept: text/html; charset=utf-8; profile=\"https://www.mediawiki.org/wiki/Specs/HTML/2.8.0\"" should force the return of 2.8.0 content, however, because 2.8.0 is the default version now, it's deemed acceptable to return content from the parsercache and, if found, 2.7.0 content will be returned, which isn't semantically correct.
In other words, HtmlOutputRendererHelper->isCacheable is sufficient for telling when we want to enter something into the cache, as is, but some other signal is needed to evict stale entries when the default changes.
Note that this is only necessary when the new default version is explicitly requested. Parsoid::resolveContentVersion might return the new default version but returning the cached content was still fine. For example, 2.6.0 resolved to 2.8.0 but 2.7.0 is still fine to serve. The point of this note is to say that, for the most part, after a version bump, requests are likely to either not have an explicit accept header or still be requesting an older version that's semantically equivalent to what's cached, and we want to continue to serve that, despite Parsoid::resolveContentVersion resolve to the new default.
