The only problem I have with the latter is that blocking beyond IP and/or port blocking is not handled by the directories.
Not only that, but the directory structure doesn't scale to those of us that need large exit policies.
I ran a 10MB/sec exit node at my .edu for a while, and it was ultimately the politics of people ripping off journal articles, accessible since we have a /16 netblock and that's how the journal services differentiate an "on-campus" versus "off-campus" user (yes, I know that's a bad idea, but that's how they do it) that made me shut it down.
I have thousands of IPs I'd need to block .. and it's detrimental to TOR to "fib" about what you'll exit (I tried lying via /etc/hosts, and later nullrouting with ipfw .. BOTH were a BAD idea, but the only thing I could think of).
How about this idea .. what if a TOR server could send a reply back to the client (via the TOR network) that says "my local exit policy prohibits that". It could be a HTTP status code, a TCP flag, anything .. not as efficient as telling the client to not try in the first place, but better than just breaking it without notifying.
(I mention the HTTP code because that would be easy to implement in a proxy, and the TCP mangling because it'd be easy with NetFilter).
Performance-wise, you'd want to cache the list of "nodes/can't-do's" in memory, since you wouldn't want that stuff written to disk (ever). That might be the Achile's heel in my idea.
Cheers, Michael Holstein CISSP GCIA Cleveland State University