First off, I'm trying to ensure due diligence and not duplicate questions that have come up before. There are numerous posts on stackexchange, and various other places, that discuss views caching and even some specifics about the different types of view caches (e.g., here and here). However, I've yet to find any details that sufficiently explain the relationships between different layers of views caching, and how they may impact case-specific caching decisions. For simplicity I'm also focusing the scope of this question to out-of-the box views 7.x-3.x caching options independent of other layers offered in the contrib space.
Views exposes 2 layers of time-based caching for each display, a "query results" cache and a "rendered output" cache. The specifics of what raw data each cache encompasses is clear, but the ways they interact is not. I'm specifically wondering if a hit on the rendered cache will completely bypass they query cache, or if the 2 layers operate separately. I've seen some references that claim the former (like this one), and some that claim the latter (like this one).
Theory 1 - Separate cache layers
I was initially under the impression (and hoping) that each layer is invoked separately "in series", and that the rendered output cache hashes the actual query results within its cids. This way I would have an elegant way to cache the most expensive post-query load/build work, while still ensuring that new content is immediately reflected in the view ("query results" cache off and "rendered output" cache on). Some quick tests reveal that this might not be possible though, as the rendered output cache may not be aware of the current query results.
Theory 2 - Rendered output cache "encompasses" query results cache
The other possibility is that the rendered results cache is keyed by a hash of the query itself (not the results). If this were the case, a hit on it could return the rendered output directly, without the need to consult the query cache, or DB. If this were the case then I suppose it would not make much sense to have the "query results" cache set with a time interval less-than the "rendered results" cache. The advantage of course would be that one could refresh the rendered output more frequently (if they have lots of dynamic theme logic, or frequent entity updates), while still avoiding direct queries to the DB. However, for all but the most complex view queries, this kind of separation does not seem all that advantageous.
I've done some "black box" tests that point to theory 2, but I'm not sure if there are some other settings that might be at play or if the answer differs by views version. I've also explored the code a bit, but I find it frustrating that most views' plugin methods are undocumented and occasionally hard to follow. No matter what, I think the answer to this would be useful to have as a reference for others.