If you have used the devel module, you'd probably know about the nifty Switch user tool that is available as a block for use in a site. It allows users with the required permission to switch from the block as any other user.

I notice that while switching between users, the session ID of the user as whom you initially logged in to the Drupal site for the first time is re-used for all switched users i.e. In {sessions}, the uid column is simply changed while {sessions}.sid or {sessions}.ssid persists.

A problem with this approach is that the session data ({sessions}.data) (saved using the $_SESSION superglobal) remains the same even for switched users which isn't good to test the application logic sometimes (at least not in my case).

Is there an elegant way to clear the session data of the old user on switch? If not, how can this be solved?

Clearing $_SESSION data may break things. I would advice not to do it. If you have to, you have to provide us a list of modules that may write to it - but then I don't believe anyone would make a full review of them, one after one. Is alternative solution acceptable?
– MołotJul 8 '13 at 12:28

Perfectly fine with an alternate solution. But could you give me an example of something that'd break if I clear session data. Isn't Switch user supposed to mimic user log out + log in which in turn mean destroying the session in the traditional sense right?
– Amarnath RavikumarJul 8 '13 at 12:44

Switching user would be perfectly all right. It's just switching back what may be broken - module would be free to expect some data in $_SESSION and that data would simply not be there anymore. Any chance to refactor your modules so they would use proper Drupal storage? If so, I can provide answer how.
– MołotJul 8 '13 at 12:46

That way you will allow Drupal to benefit from database permanency, memcached speed, whatever you please. And by including uid of current user, you are sure data is well separated and no collisions will occur. Including session ID allows proper anonymous user handling. For logged in part $user->sid might be safe to ignore, depends if you want data to be shared between logged in seats or not.

If you use session id as a part of cache key, like above, entries will be only valid for one session. If your site has few users, obsolete cache entries are not a problem. And if you have many, you should store both sessions and cache in memcached, apc or similar technology anyway. Database is simply to slow for this. Memory based cache engines are very good at automatically destroying unused entries when needed, destroying them from code is a waste of time and effort.

Looks good. Only that the type of information I'd like to store is heavily session-dependent. Eg. Imagine Has the SSO for this user been done for this session yet? Entries in {cache} are cleared on the normal cache wipe - however, in this case, I will want to clear only those cache entries whose sessions (from the session ID in the key) have expired which could also make it slightly more complex.
– Amarnath RavikumarJul 9 '13 at 3:24

@AmarnathRavikumar Answer updated. Long story short, it's not a problem. Don't reinvent the wheel, no need to.
– MołotJul 9 '13 at 7:09