On review, setCacheNames is really a configuration-time method and not meant to be called at runtime when caches already exist. That said, point taken that it can effectively be used for re-configuration purposes as well, so we need to take that into account to some degree.

For the specific case of "leaking" dynamic cache regions when a new set of fixed cache names is being configured, these formerly registered dynamic regions keep being accessible, so they are not really leaking. Also, if a specific set of cache names is set through setCacheNames initially, and then later on a smaller or different set of cache names is set on yet another setCacheNames call, we are not removing the old caches either, rather just adding the newly specified ones. The registerCustomCache facility makes the semantics even less clear there since those are always worth retaining.

Overall, I don't see us adding official clean-up semantics to setCacheNames. Instead, we're introducing a resetCaches() method (#35840) which can be called before setCacheNames if such clean-up is desirable: That method can generally be used for cache clearing at runtime, removing dynamic caches or simply clearing static caches. This goes nicely with the existing removeCache method that we introduced in 6.1.15 (#33813).

Thanks for the PR, in any case!

Thanks for the detailed explanation, Juergen.

I understand the design philosophy regarding setCacheNames as a configuration-time method and the risk of implicit cleanup. Introducing an explicit resetCaches() method seems like a much safer and more flexible approach to handle runtime reconfiguration scenarios.

I'm glad that my report contributed to improving the cache management capabilities. Thanks for addressing this!