Thanks for the wiki link. :)
You say that "The class loader isolation for each app ensures that user code can use JBC 2.x while the app server still uses 1.4.x for its own clustering." Recommend that you spell out how that class loader isolation was achieved -- that's the key piece of info readers need to understand.
I'm guessing you did it just by putting JBC 2.x and all its dependencies in WEB-INF/lib and counting on the fact that a webapp uses a child-first classloader.
Re: PojoCache vs core cache, when I look at the stack trace on http://www.jboss.com/index.html?module=bb&op=viewtopic&t=128465 I see it's failing in constructing a CacheImpl. That doesn't seem like something that would only fail in the PojoCache case. I suspect Pete hasn't done whatever you did to get the needed class loader isolation.
The JBossCacheAsCompatibility wiki page is a bit confusing, in that it provides a sample deployable WAR file that uses JBC 2.x, but without the relevant JAR files, and does not list which JAR files from the JBC distro should be included, and which are unnecessary.
I'm trying to deploy an EAR containing JBC 2.2.0 within EAP 4.2, and when I include jboss-common-core.jar, I get ClassDefNotFoundErrors for ThreadPoolMBean, which is likely because jboss-common-core.jar eclipses some classes from JBossAS but not others, so the classloader gets into a spin.
If I omit jboss-common-core.jar, then it instead it can't find MarshalledValueInputStream, which is present in JBossAS but in a different package.
No combination of JARs from the 2.2.0, 2.1.0 or 2.0.0 distro seems to work in my EAP 4.2 when packed in an EAR.