session_regenerate_id() only resets the current session id.
Nothing else.

Thanks for your reply, Sniper.
This has been the opportunity to understand I've been somewhat too elliptic...
So, if you allow, I will try to restate what I had in mind.

Let's say I have defined my own session storage management through 6 functions (the args for session_set_save_handler()).
On ***my*** system, the behavior seems to be as follows:

Call to sessions_start():
1. _open() gets called
2. _read($id) gets called
3. _gc($time) may be called (according to the "probability")
Then, upon script completion:
4. _write($id, $data) gets called
5. _close() gets called

Now, if session_regenerate_id() is called after session_start(), argument $id in step 4. indeed differs from what it was in step 2.
And this could be used as an indication that an id regeneration has been performed, thus needing some housekeeping.
BUT...

Above description (steps 1. through 5.) is not explicitely documented, and thus by no means has an official status: it is just empirical.

Thus, a first question is: "Does aforementioned change in $id occur through AND ONLY THROUGH a call to session_regenerate_id()?"

Moreover, the documentation states: "The write handler is not executed if the session contains no data; this applies even if empty session variables are registered".
On ***my*** system, _write($id, $data) seems to be allways called.
But if the documentation is right (and my system being thus bogus), it couldn't be relied anymore upon a change in the value of argument id (as step 4. wouldn't occur).

Another question is thus: "Could session_id() be reliably used in place to track a possible call to session_regenerate_id()?".

Again, such a question occurs because trials tend to show that session_id() indeed reflects the effects of session_regenerate_id(), but this too is empirical only.
I would feel more confident if the documentation established true and explicit cross-references for session_id() and session_regenerate_id().

Another formulation could be as follows.
A. _read($id), _write($id, $data) and _destroy($id) all have an argument for a session-id.
B. session_id() allows to read a "current" session-id.
C. session_regenerate_id() allows to operate upon a "current" session-id.
May it be taken for granted that all those things systematically refer to the same entity, so that they are allways in sync?
Or does one really need some kind of feedback in the user-defined session functions upon a call of session_regenerate_id()?

Could just be a kind of documentation "bug".
Anyway, thanks again for the follow-up.

Yes, the documentation should be cleared up a bit.

if using a user based session handler, php should go the long way in changing a session id. Currently php just changes the session id on an existing session stored, this is fine and good with like files (havent tested sqlite), but with user, creates some problems. The session handler just creates a new session, so you have two active, and keeps the data in the first, and the second one empty. PHP should really copy all data, destroy the old session, create the new session, and import the data into the new session. This avoids any issues with some session handlers that exist these days.

thats my opinion anyway, better compatibility, even though theres a little overhead added.

Unless this is handled differently for the default (file-based) session handler, the current implementation of session_regenerate_id() would leave stale files (possibly containing sensitive session data). I agree with nathan php should go the long way and make sure to destroy the old session.

About the calling of the write function of user defined session handlers even on empty sessions, ages ago I reported this bug:

http://bugs.php.net/bug.php?id=25954


I think this should either be fixed in the documentation, or (if this is unwanted behaviour) in PHP itself.

PHP MUST call the user functions to destroy the old session data. The now working way is a high risk, because people expect another implementation than it is now.

There is nothing wrong with the function. RTFM.