fixing bug 32621 is a todo. The first attempt failed and some tweaks are needed to use the PathRouter to fix that bug.
PathRouter allows for the use of custom paths to expand. NamespacePaths is an example of one thing you can do (say giving Help: pages a /help/ path) but you could also apply that to special pages, etc... whatever. It's also the precursor to MW being able to handle 404s natively. The plan is in the future you'll just be able to throw everything that's not a file right at index.php and pretty urls, 404 pages, 404 thumbnail handlers, etc... will all just work natively without any special configuration.
And by 404, I don't mean standard 404 pages like this: http://wiki.commonjs.org/404 I mean nice in-site 404 pages that actually help visitors find what they were looking for: http://www.dragonballencyclopedia.com/404
Not sure how PATH_INFO being unmangled fixes anything. There are other servers where PATH_INFO won't easily be outputted. REQUEST_URI handling works better in every case. And ?title=$1 in rewrite rules are evil. Determining what urls run what code has always been the job of the application in every good language, not the webserver. And we can do it using REQUEST_URI much more reliably than some webservers. Anyways, I wish I could just get rid of the PATH_INFO code. I have yet to hear of someone actually using it now that practically every webserver there is outputs REQUEST_URI meaning the PATH_INFO code is never reached.
Thanks for answering! But wasn't all that possible with just using something like $wgActionPaths? Unmangled PATH_INFO allows for a single rewrite rule like (.*) -> index.php/$1 to and you won't need to strip base from URIs (yet of course it's not hard) And you say PATH_INFO is unavailable on some configurations - can you please clarify what are these configurations?