ScopedValue-based implementation of SecurityContextHolderStrategy

Spring Framework provides an extensive support for virtual threads. Virtual thread guidelines, however, recommend to replace the ThreadLocal with ScopedValue while Spring Security is one of the systems which uses ThreadLocals extensively - its default implementation of SecurityContextHolderStrategy is ThreadLocal-based. Although it hasn't been officially announced, as of JDK 25 ScopedValue is no longer annotated with PreviewFeature.

Does it make sense to implement ScopedValue-based SecurityContextHolderStrategy - even though the SecurityContext or Authentication are not necessarily expensive reusable objects as the Oracle guidelines state?

This issue has been addressed more than a year ago in a Stack Overflow thread Spring Security Virtual Threads and ThreadLocal and in my answer to it. The small POC project, brought in the answer, offers some solution to this issue; this solution, non-systematic and ad-hoc, may, nevertheless, serve as a starting point of the discussion. The problems and ramifications of the solution are also discussed in a readme file of the project.

Begin with SecurityContextHolderStrategy and the default ThreadLocal-based implementation; compare their context-lifetime assumptions with the ScopedValue guidance and the linked POC's README. Done means a repository-grounded decision on feasibility, ramifications, and the scope of a systematic strategy; no repository file or test is named in the issue.