The `stale` mechanism for view queries conflates two independent
1. Whether or not the view results should be returned from a "stable"
set of shards; i.e., mem3:ushards. This semantic is new in 2.0,
having originated in Cloudant code in 2011.
2. Whether or not the view in question should be updated prior to
responding to the user, i.e., the pre-2.0 semantics.
Both of these concerns represent consistency/availability tradeoffs, but
they're addressing rather different aspects of that continuum. As such,
the "stale" mechanism limits flexibility.
For example, it's quite likely that a user would want to retrieve
"stale" view responses from the fastest available shards - the
"available/available" choice - and this choice is not available with the
existing "stale" mechanism. A similar argument could be made for the