Could you please provide a test script showing the behaviour you're describing. 
Based on what you've written, I do not know what needs to be documented.

$url = 
'http://example.com/key1=val1&key2=valsƈs&key3=vals&apos3;#fragment';

echo '<xmp>';
var_dump(parse_url($url));
echo '</xmp>';

actual output:
array(4) {
  ["scheme"]=>
  string(4) "http"
  ["host"]=>
  string(11) "example.com"
  ["path"]=>
  string(21) "/key1=val1&key2=vals&"
  ["fragment"]=>
  string(31) "39;2s&key3=vals&apos;3#fragment"
}

expected output (unless documented):
array(4) {
  ["scheme"]=>
  string(4) "http"
  ["host"]=>
  string(11) "example.com"
  ["path"]=>
  string(21) "/key1=val1&key2=vals&#39;2s&key3=vals&apos;3"
  ["fragment"]=>
  string(31) "fragment"
}

Hash characters are not valid within a URL, except to delimit a fragment. RFC 
1738 (http://www.ietf.org/rfc/rfc1738.txt) explicitly indicates under "2.2. URL 
Character Encoding Issues" that the hash character *must* be encoded for the URL 
to be valid.

The parse_url() reference indicates in several places that malformed URLs will 
likely incur issues. As such, I don't feel it's warranted to document each way a 
URL can be malformed.

fair enough.

imho, as parse_url actually splits on fragment (which i would assume isnt 
actually sent in the HTTP request of a URL), i expected parse_url() to work on 
URLs found in the wild (ie. URLs intended for a browsers address bar, xHTML 
display) eg. a URL captured from a page anchor href tag.

but again, i wouldnt have realised that a URL encoded with a HTML entity 
(regardless of proper context) would be considered malformed.