Remember that these tests are not how user code would typically interact with the library.
Beyond that, I agree that eople would start referring to tests and copy stuff. A lot of the test cases were carried forward from the 1.x series where certain methods such as locks, etc. were available in TreeCache and these were used to test outcomes of operations. The quickest way to port the tests was to use a cast. In future this will go away, using proper mock objects or interceptors where possible, to inspect internals.
The purpose of the SPIs are to provide an insight into the cache internals. Internals that are not needed for normal usage. These are available to people extending the cache or writing plugins, such as eviction policies, cache loaders and interceptors.
If you are looking at changing the way locks work (upgrading if necessary) I'd recommend extending the PessimisticLockInterceptor.
I'll look into the PessimisticLockInterceptor