A couple points:
Phillip is working on another draft, mostly trying to make some of the text easier to understand.
Thread support: I think it's a little weird too, as it's mostly just broken if you are running without threads in a single process. I'm not entirely sure how well this would support an asynchronous application, which would allow single-process, single-thread concurrent programs. Right now environ['wsgi.input'] only is specified to have a blocking interface (AFAICT). This may be the only place that's a problem, and an extension could allow interested programs to avoid that. Right now I don't believe there are any Twisted people actively giving feedback on this, which is too bad.
Features (or lack of): as the PEP says, this isn't meant to be a replacement framework, rather its a foundation upon which you can build frameworks (or port frameworks). This doesn't preclude featureful frameworks built on top of WSGI in any way. Most of the features you note from mod_python could be implemented just as easily on top of WSGI. There are some features that wouldn't be supported -- like mod_python's ability to put hooks into different places of the request, do a local redirect or recursive redirect, etc. But even in these cases, mod_python could provide extensions to provide these features as well, the spec specifically allows for these kind of extensions.
The value added with WSGI is not that suddenly you will have great new features. Instead, it's a foundation so that when developers add new features, they can share them outside of their personal framework. Or, when there are new server targets, those too can be used with other frameworks. I think this can lead to a more organic development of standards -- when people are able to choose features and implementations in a more granular manner, they can be more discriminating. This way we can slowly get past diversity, as people choose the best solutions for particular aspects of the system.