Right, it's definitely possible to work around this problem using proxy children, but going forward I don't think that's how Twisted *should* behave.

(I actually tried this, and nope, it's not exactly pretty :-( )

The reason for that is that that would mean there's two ways to do things. Suppose a child is missing. In the case of a blocking/immediate lookup, you'd return an error resource from getChild. In the case of an asynchronous lookup, you'd return a resource immediately, regardless of whether the lookup fails or not (since you don't know yet) whose render method returns NOT_DONE_YET and eventually finishes a request.

If getChild supported deferreds, you'd return an deferred error page from getChild in the asynchronous case, and you'd return the error page as you always have in the synchronous case.

That makes a lot more sense to me. What I want is "so, there's a value (==IResource), but I don't know what it is yet", and it seems to me the natural way of expressing that in Twisted is a Deferred.