> That would make more sense if there was an expectation that people might want to change it, as might be the case for logging (the PR of which seems to have stalled meh) but in this case, I'm not sure why you would want to change it. For owncloud you say "the cache can be easily replaced with an implementation that persists over requests, e.g. xCache" but I'm not sure persisting a stat cache over multiple requests is a good idea. The statcache, in PHP, causes enough problems as is, without persistence. I understand why it's done but idk.. if there's a valid use case for why you'd want to change it I'd be more willing to consider it.

The specific reasons I gave in that PR do not all apply here. I do not think that having a persistent cache in this case would be a good idea. In the case of the linked PR there is a gain in consistency even though the cache is only volatile, and as a result the cache implementation basically gets unit tests for free.

Nevertheless, from an architecture view, it is better to have a collection of small, well-defined, reusable, unit-tested classes instead of having huge classes (as is generally the case throughout phpseclib). PHP4 does not have enough OOP features, for example lacks interfaces and does not come with autoloading, which in the end leads people to put everything into a single class or file.