Closing as resolved.  If this was an issue, there was a fix associated 
with this ticket that would have likely solved it.  And nobody has 
shown that invalid cached data (e.g. switching compression) will not 
be correctly invalidated.

Changes have been made in Git (master):

commit dc062d88fa534e968fe260d3bfe8032205f5b6d8
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Tue Mar 5 18:22:05 2013 -0700

     [mms] Fix regression preventing compression of Horde_Cache data 
(Bug #12088).

  framework/Cache/lib/Horde/Cache.php |    6 +-----
  framework/Cache/package.xml         |    4 ++--
  2 files changed, 3 insertions(+), 7 deletions(-)

http://git.horde.org/horde-git/-/commit/dc062d88fa534e968fe260d3bfe8032205f5b6d8

D'oh.  Turns out that I essentially wrote the 'compress' parameter in 
Horde_Cache out of the class.  So this could have possibly left things 
in an inconsistent state (also why I would not see any difference 
moving through the various compressions strategies).

I'm releasing Horde_Cache 2.0.3 with this fix.  Cycling through the 
compression strategies without clearing the cache, I don't run into 
any issues.

1) I just transitioned from LZ4->LZF->None->LZ4 (separate logins for 
each) and saw no warnings (even in debug logs).
2) What you are asking for is impossible anyway. There is no 
requirement that a Horde cache backend allows you to expire all keys 
(see, e.g., memcache).

If that is happening then obviously it needs to be fixed.

But any invalid cache data should never cause any problems because, by 
definition, cache must never be counted on as being available.

I had some reproducable fatal errors when I switched from no 
compression to lz4. I will check later to get the full error message.

No it won't.  In fact, I have not once cleared my cache that was 
previously stored with lzf compression and everything works fine.

I specifically made sure that horde_lzf fails gracefully if it tries 
to decompress non-lz4 compressed data.  In this case, it returns false 
which counts as a cache-miss.  Which is no big deal and something we 
do all the time (e.g. changing the serialize format of an object).

Sure - if someone upgrades when active sessions are active that 
session will likely be terminated.  But so what?  That could be said 
about any number of changes that would break active sessions.  We've 
never supported in-place upgrading of active sessions.

Once horde_lz4 is stable, or even earlier when user have 
preferred_state=beta set, upgrading with -a will install the extension 
(even though not activating it by default). This will break existing 
caches though, probably as would installing/uninstalling lzf. We need 
to handle this more gracefully, because this might happen without 
explicit user interaction. A suggestion to run horde-clear-cache in 
INSTALL or UPGRADING wouldn't suffice.