Description:
------------
The order is session open, session read, session gc.

This applies to the case where the garbage collector is triggered by the client 
X and the session is of client X.

The session variables are available in script, but the sessionfile is deleted 
and no write of the session takes place.

For the php user and the php application user there is the impression that the 
session still is alive.

Example:
User is logged in with cookie with sessionid in an admin application and is 
logged in as admin which is registerred in the session.
Has admin form bookmarked or in history.
Php script does gc removes sessionfile.
But the session variables indicate that the user is logged in and so the script 
spits out the form.
User does a post and poof suddenly there is no session.

This is seemingly random behaviour and no ordinary php programmer and user has 
any idea what is going on.

This sounds like one in a million but could happen quite often with a database 
application in a small business.

So either the session should be removed before open and read, which I understand 
you won't do (Bug #35479) 
or it should be continued and rewritten to file, which is what the bahaviour 
when you write the most straightforward handler for a session database

Also as a dev. how do I know it is garbage collected? 

Test script:
---------------
setup:
ubuntu package mod php 5.3.10 on apache2 mpm prefork

relevant and changed ini setting:
session.gc_maxlifetime = 1
session.save_path = /tmp



Expected result:
----------------
session that is garbage collected by invocation of session owner (http client) is 
rewritten to a new file

Actual result:
--------------
session variables are available but session is effectively destroyed, giving the 
impression that the session is still live when it is not