"The purpose of the SecurityContextHolderStrategy isn't intended to be for the creation of different security context types" fair enough, but because of the way it simply news a SecrurityContextImpl, it's inconsistent with how the HSCIF creates new SecurityContext impls.
So in my case, I need a custom SecurityContext impl. I set that class in the HSCIF bean definition. But, I have code that go right at the SecurityContextHolder whose default strategy is to new the default SecurityContextImpl. In the case where my code needs the custom impl and the current thread has not passed through the HSCIF, this then fails.
It's mainly an issue for test code, but it also applies to things like worker threads which will not pass through the HSCIF.
Ideally, I would just define the SecurityContext impl class once and be done with. As it stands, to get the behavior I need, I had to subclass ThreadLocalSecurityContextHolderStrategy and change the way contexts are created by getContext to prevent the default strategy from handing out the wrong SecurityContext implementation. That even wouldn't be so bad, but I have to keep it in sync with the HSCIF. The creation pattern for SecurityContext should be the same across the system, maintaining it through two different bean config mechanisms is error prone.