for me the bug creeps up in old, stable code that suddently doesn't work any more. 

as original poster said, IE works fine, FF does not. The bug is also not present in konqueror (kde browser)  nor epiphany (gnome browser)

As OP said, strings entered to the session object (in my case indirectly  via some custom classes) are kept, values from database seems kept, values from queries (GET/POST) are dropped. 

My server runs Linux (Gentoo, mostly stable)

You're not using PHP 5.2.5 in any place? I'd suggest upgrading first. And then check what your session.* settings are in your php.ini file. (or rather from the phpinfo(); output)

Since posting my ever helpful sysops have moved 
http://cms-stu-iis.gre.ac.uk/mk05/session/index.php
to PHP 5.2.5 and I have recently installed 5.2.5 onto Apache 2.2.8
The bug still manifests.

I am not sure why jani asks for session settings as the sessions work correctly in all browsers other than Moz and work but incorrectly in all Moz browsers, but if it helps these can be found at
http://staffweb.cms.gre.ac.uk/~mk05/info.php
http://stuweb.cms.gre.ac.uk/~mk05/info.php
http://cms-stu-iis.gre.ac.uk/mk05/info.php

I am slightly puzzled as to how this bug has lived so long as it is causing dreadful problems for my poor students.

As to the underlying mechanism... 
I think, but don't know, and I am not terribly confident but...

Perhaps Moz clients send an HTTP GET request for register.php when they encounter the empty href attribute in the <link> element. This would overwrite the SESSION entries causing them to lose their value, which is what we see. Although if this is happening then why do we not see Undefined index warnings raised by the POST variables not existing (which is what you see if you GET register.php).

Ah yes..that empty link definately will cause problems.
I guess Mozilla based browsers are more strict in this, IE is known to allow pretty much any crap. :)

I tested your page using FF and having Firebug installed, and it does 2 requests for index.php. For example this bug page only shows 1 request.

This is not really any PHP bug just how decent browsers behave. You shouldn't have empty links like that around anyway.

See also bug #10599 and bug #33705

Yes, in an ideal world pages should not have empty <link> elements. But in my less than ideal world I have students using XHML templates with empty <link> placeholders. Not surprisingly I have some pretty confused students who I am having difficulty keeping away from IE.

I can understand how an empty href attribute may cause a user agent to make an HTTP request for the file path with no file name and the server returning whatever is the default file, usually index.php or index.html.
But Moz interprets the empty href attribute value as being the filename, which isn't really all that sensible.
And... surely the browser should be sensible enough to realise that the HTTP response isn't text/css.

Before I pass this over to the good people at Moz there remains an unresolved PHP problem...

If this effect is caused by Moz sending a GET request for register.php we should see warnings.
This is a simple enough experiment.  Instead of refreshing register.php (in which case the browser will want to resend the POST data), click in the browser address bar and hit Enter to force it to GET register.php - hey presto - warnings.

Put this line in the register.php:

var_dump($_POST);

According to Firebug, it doesn't send anything. Why it doesn't cause a notice I don't understand..maybe it does but for some reason it isn't outputted. You should check what is in the Apache logs. And maybe make PHP to put all errors in a separate file.

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".