I thought this is a suspended issue.
But I cannot find report..

Except location of,
<INPUT TYPE="hidden" NAME="SID" VALUE="[someSID] />

We can fix other issues.

Please add short script which can be used to reproduce this
and also your url_rewriter.tags line from your php.ini

A simple example script:

<?php
session_start();
echo<<<EOF
<form method="get">
See hidden input<input type="submit" name="submit" value="Test" />
</form>
<a href="$PHP_SELF?foo=bar">See new href</a>
EOF;
?>

The url_rewriter.tags value:
a=href,area=href,frame=src,form=fakeentry

This is the output with PHP 4.2.0:

---clip---
<form method="get"><input type="hidden" name="PHPSESSID" value="25ba3c5303803bb6914edff4d787b430" />
See hidden input<input type="submit" name="submit" value="Test" />
</form>
<a href="/ses.php?foo=bar&amp;PHPSESSID=25ba3c5303803bb6914edff4d787b430">See new href</a>
---clip---

Which part is not valid XHTML?

I have this set in my php.ini:

; The separator used in PHP generated URLs to separate arguments.
; Default is "&". 
arg_separator.output = "&amp;"

That output will become valid XHTML with the addition of an "id" parameter for the input tag.  Since "id" is XHTML's replacement for the deprecated HTML "name"  attribute, the usual method for making markup backward-compatible is to use both "name" and "id" attributes, giving the same value for both. For example:

<input type="hidden" name="PHPSESSID" id="PHPSESSID"
value="25ba3c5303803bb6914edff4d787b430" />

Fixed in CVS

note that this is not correct with regards to input elements. the name attribute is only deprecated for the a, applet, form, frame, iframe, img, and map elements. (see C.8 of the xhtml spec, and the dtds.)

in fact, reverting this part of the patch would be a good idea. we're defining input element names here, not fragment identifiers.

It should not be reversed.

The XHTML DTDs defines "id" as one of the core attributes (see parameter entity "coreattrs") for most elements, including the input element.

Section C.8 states "In XML, URI-references [RFC2396] that end with fragment identifiers of the form "#foo" do not refer to elements with an attribute name="foo"; rather, they refer to elements with an attribute defined to be of type ID, e.g., the id attribute in HTML 4. Many existing HTML clients don't support the use of ID-type attributes in this way, so identical values may be supplied for both of these attributes to ensure maximum forward and backward compatibility (e.g., <a id="foo" name="foo">...</a>)."

One of the features of XML (and therefore XHTML), is that anchor elements are no longer the only elements addressable by a fragment identifier.  Note that section 3.2 states "When a user agent processes an XHTML document as generic XML, it shall only recognize attributes of type ID (e.g. the id attribute on most XHTML elements) as fragment identifiers." So while "script.php#PHPSESSID" may sound like an unlikely path, it is a legal one.

we are *not* generating fragments that are expected to identified by their url. we are generating a (hidden) form input element with a name. we expect the browser to submit the value of that element with the associated name. setting an id is pointless. (and potentially *wrong* if there is more than one form on the page, which means we'll have created two fragments with the same id.)

We're generating an element to be used in one known way (for reference by the PHP session library) and that can also be used in other legitimate ways: addressed via a fragment or XPointer, via DHTML, etc.  PHP doesn't generate markup that conforms only to its own needs, it generates it to meet authors' needs, user agents expectations, and spec requirements; the current patch does not conflict with existing specs, allows for more reliable UA recognition under certain circumstances, and makes the element more accessible to the author for legal addressing or manipulation.

The value of session.name is configurable.  So if an author finds that the hidden field's id conflicts with another element's id, they already have the option to modify either or both elements in order to avoid conflicts.

Preventing side-effects of rewriting on multi-form pages is an interesting issue. Perhaps this could be remedied with a configuration option (session.rewriting.hidden) allowing the author to designate whether the hidden input should be written with an id attribute, name attribute, or both.  That would permit for flexibility under differing contexts, including text/html, text/xhtml, and text/xml.  The default value would remain as before: "name" (only); but give authors the option to change the behavior when needed.

now you're just making up reasons to waste bandwidth and create a silly configuration knob. the patch has been reverted. the existing output is entirely sufficient for all of the purposes you've listed, and perfectly standards compliant.

XHTML 1.1
<form method="post" action="/de/search.html">
<input type="hidden" name="sid" value="7957363932547bc30cec8978468736bf" />
<input type="submit" name="submit" value="Test" />
</form>
=> Error: element "input" not allowed here; possible cause is an inline element containing a block- level element

You have to wrap the form in a table to be valid. An other aproach is to change url_rewriter.tags form=fakeentry to form=action. But php doesn't overwrite the default php.ini.

btw. I have to change the arg_separator.output to "&amp;" instead of "&" to be valid.

"You have to wrap the form in a table to be valid."

Not necessarily in a table. Any block element would do.