If I understand correctly, darcs record compares the unrecorded + pending 
state to the pristine state, yet issue2093 shows us an example where 
darcs record seems to be trying to retrive patch files.

So should it be the case that darcs record on a --lazy repo never needs 
to fetch any patches? Isn't it just adding things?

One possible reason may be that it's not actually interested in the 
patches per se, but that the fetching of patches is some incidental side 
effect related to say, reading an inventory.  If so, that sounds like a 
bug of some sort.

But focus.  Is the behaviour inherently buggy?  We need to think of some 
circumstances where darcs record fetching patches would be a right thing 
to do.

We need a confirmation that the repo from issue2093 was indeed --lazy.
If not we need to know why the files were missing.

OK, waiting-for issue2093

I think I know what happened here.
The response from issue2093 doesn't indicate that the repository was
lazy but we know it was pulled over a mounted share.

In that situation the source repository would look like a local copy on
the same machine. I think in this situation while reading any patches
darcs defaults to checking the source destination first. I'm not even
sure that all patches are copied in such cases.

The behavior I am referring to is nicely described in:
http://wiki.darcs.net/Internals/CacheSystem#retrieving-hashed-files

OK, we can't confirm if the repo was lazy or otherwise (no log, no 
memory).  

Adam's reading gives us something nice and falsiable, the idea that if 
darcs wants a hashed file and thinks it got it from a “local” source, it 
will try to read it from that source first rather than the more 
immediate current repo.  That sounds a bit fishy (from memory), and I 
suspect it's more the case that we need to update the CacheSystem 
wording to be sure.  At this point, I think the most helpful thing would 
be to study the Darcs.Repository.Hashed{IO,Repo} code to double-check on 
this story, perhaps updating the wiki as needed.