SessionManager provides an abstraction layer for the session frontend (ie. for the question of how do we read/write session-related information from/to the web request), but is tightly coupled with the implementation of the session backend (ie. how do we read/write session-related information from/to our servers). The session backend is a BagOStuff, so there is some amount of abstraction, but once you have determined what object cache backend is used for sessions, there's not much further flexibility.
There are a couple reasons we might want to change that, mostly related to how anonymous sessions differ from authenticated session. Anonymous sessions are hard to plan for because they can be triggered by simple scraping; they are relatively low risk (an attacker who is able to manipulate an anonymous session wouldn't be able to achieve that much); and they are low-value (session loss is not very disruptive). Authenticated sessions are the opposite. So we might want to have differences in handling such as:
- use different storage groups on the same storage backend (T392170: sessionstorage namespacing)
- use a different storage backend (e.g. more loss-prone but cheaper to scale Memcached rather than Cassandra; see T362335: Simplify MediaWiki session store at WMF for some older discussions)
- use backendless sessions (T394076: Investigate storing anonymous sessions client-side)
This might be tricky because a session can go from authenticated to logged-in or vice versa, and we want to nevertheless preserve its contents (especially during login this is relevant). But we can probably handle that like we handle session ID resets. Also we need to make sure there is no situation where we don't know beforehand whether a session is authenticated or not, and it's determined by what data we read from the store (which obviously wouldn't work if authenticated-ness determines what store to use).