It appears there has been changes to how the LCL works and my memory is based on much much older version so take it as grain of salt.
When the user gets authenticated, the sessionID gets stored in the user attribute.
When another same user gets authenticated then this new sessionID gets stored in the user attribute overwriting the previous value.
When the user tries to access resources for authorization, LCL will check if the submitted sessionID matches the value stored in the user attribute.
If the value match then granted access, if not rejected.
Because it is always the latter user session that would be valid, there is actually no reason to remove the sessionID from the user attribute when the user logout, although it would be good if it did.
I think this is where you are reporting this issue and I must admit that LCL might have changed(with improvements).
When the same user tries to access the next day, assuming the MaxTimeout has already exceeded, the user must Authenticate again and the new sessionID gets written in to the user attribute.
So whatever value there was before has no meaning now.