At the risk of repeating myself, no monkeypatching is required to add wsgi: URL support -- urllib2 is designed so that adding new URL schemes and behaviour is easy iff you have access to the OpenerDirector instance (the thing you call .open(urlOrRequest) on). Titus, as the author of twill, clearly does have such access, though I don't know if it's also exposed as part of the twill API.
Point taken -- rather than breakage with wsgi:// (which I thought might be clean) I will look at subverting urllib2. The goal will be to produce a WSGI-compliant server interface into which any WSGI app can be plugged & played.
This is a good direction for twill, IMO, so I'm moderately enthusiastic about implementing it, too.
A few additional comments:
zope.testbrowser looks nice, but it's unclear to me what the compelling advantage is. I've got to look at it more before I make my life more complicated by trying to switch to it... ;)
the twill API doesn't provide direct access to anything mechanize-tic, but the full mechanize interface is of course accessible to extension functions, which are just Python (of course!).
Finally, even if twill becomes WSGI-aware, writing the tests is going to be a huge pain. (Hmm, maybe if I get the BickingBot entangled in twill he'll write a WSGI recorder!)
Simple (but working) implementation of in-process testing with twill: <a href="http://www.advogato.org/person/titus/diary.html?start=119">discussed here</a>.