Hey Justin,
good that somebody wraps up his sleeves and tries out the stuff 
Not sure from the top of my head about the result cache size settings - I would have guessed that this would be a global size. Maybe it's again more something like a guideline then a strict rule (you know, if we have the memory, why not just use it until we need it for something else?).
The invalidation of the cache of course needs to depend on the queries or more precisely on the transactions the queries run in. If the underlying data had been changed in whatever way (technically speaking, if the maximum change transaction of the underlying data is newer than the one of the cache entries *and* the transaction that wants to read the data is also newer - very likely the case - then the cache cannot be used for this query).
If no transactions exist anymore that could potentially be interested in the cache data, the entries are free to be released (when ever that might occur - no hurry, though).
In layman terms: when you want to use the query cache on real time replicated data, you will only see invalid cache entries all the time, since the data is constantly changed.
As operational reporting models are one of the more tricky modelling challenges, where you would like to have something like that, it's a bit disappointing to not be able to leverage the cache for that.
On the other hand, when you load in a controlled way and can accept the slower first query execution for the cache filling, then it might be useful.
Really, it's *very* close to what the OLAP cache in SAP BW does.
Cheers,
- Lars