The new version (e.g. SecurityContextRepositoryFilter) would have a pluggable strategy (SecurityContextRepository) which would be called to load and save the security context between requests:
SecurityContext loadContext(HttpRequestResponseHolder requestResponseHolder);
void saveContext(SecurityContext context, HttpServletRequest request, HttpServletResponse response);
HttpRequestResponseHolder would hold both the request and response objects, allowing the call to return wrapped versions of these if required. The returned versions would be passed to the filter chain and also to the saveContext method, allowing the implementation to retrieve additional state information it might need.
The filter would be greatly simplified and the existing HttpSession storage mechanism would be refactored into the default repository implementation.
This would have two benefits (aside from making the code clearer) :
1. It would allow customization of the filter through the namespace, by providing a the repository as a plugin point (the filter itself would be very basic).
2. It would allow for other security context persistence scenarios - e.g. the context could be stored as an encrypted session cookie, without maintaining state on the server side.