Alright, I finally got motivated enough by some questions and circumstances to do this brain-dump of IIS6 Request Processing Internals. I will most likely be missing some details here and there so I welcome followup, but I just want to get something down first and worry about completeness later. Else, I would probably never find the time to finish this...
At a high level, IIS performs a very simple task - for every requested URL, determine a handler to "handle" the request and optionally generate a response (though it is highly suggested to generate a response, for the poor web browser's sake...). Along the way, server-side binary code can execute during various phases of request processing as well as be the "handler" of the request.
What I am going to talk about is the "determination of the handler to handle the request" portion. Note: I am ignoring WebDAV and a couple of other complications for the sake of conceptual clarity.
The request processing sequence looks like the following:
Only when the wildcard application mapping returns and tells IIS "I am NOT handling this request" does IIS invoke the next wildcard application mapping... until IIS either goes through all wildcard application mappings or some wildcard application mapping declares "I AM handling this request".
If no wildcard application mapping handled the request, continue on; else, consider the request handled.
If there is a match, then IIS invokes the script engine of the associated application mapping and considers the request handled.
For the security conscious - when an ISAPI DLL or CGI EXE is invoked, either as the script engine of a normal application mapping or wildcard application mapping, or directly as-is, the "Web Service Extension Restriction List" kicks in to validate that the ISAPI/CGI is enabled. If not enabled, handle with a 404.2 custom error response.
Likewise, when the Static File Handler decides to send an existent file resource, it looks up the MIMEType for the given resource extension. If it fails to match, then handle with a 404.3 custom error response.
The astute reader should realize that the key difference between a wildcard application mapping and a normal application mapping is that a wildcard application mapping can return "I am NOT handling this request" and pass the request along, while normal application mapping MUST handle the request. This distinction is what makes all ISAPI that are NOT written to be a wildcard application mapping UNABLE to function as a proper wildcard application mapping.
Let's look at the entire request process sequence as it applies to a juicy courtesy 302 redirection to a default.document static file which has a known MIME Type defined for ".document".
There are lots of possibilities to discuss at this point. I will see where people want to take it...