Xavier, what do you think? I almost find it better this way; it ensures you have a copy of any synced package on your system.
http://projects.archlinux.org/pacman.git/commit/?id=4476598e4e128f4595d5383ecb51a9576a447b5b

Funny, I was searching the changes we did to file:/ handling to refresh my memory, so I also just looked at this commit.
I don't think it's directly related however. With or without that commit, we always did a copy from the file:/ repo to the cache.
The only thing that changed is how we did that copy : let libdownload or external downloader handle it, or do it manually.
It went this way :
1) force libdownload usage for file:/ (this is wrong)
2) handle file:/ manually (this sucks, because libdownload handling is much better)
3) no special file:/ handling (this sucks because wget does not handle file:/ . but its still the best option)
I just thought of an other option, which I don't remember even considering back then :
4) handle file:/ manually when external downloader is used. But this can have the same drawback as 2) : the support by external downloader for file:/ could be better than our own

In all these cases, we never considered to avoid copying the file to the cache. So I believe all the above is off-topic and not relevant to this bug.

Now what do you mean by "it ensures you have a copy of any synced package on your system" ? Are you thinking about mounted network share ?
The first/default cachedir could be a mounted network share itself so it's not a 100% guarantee.

Anyway, my first thought when I read this bug was : why don't we automatically add a file:/ repo as an additional cachedir.
My after thought is : the user can already do that himself, and this gives him more control.

Pierre, what happens if you add the following lines to your pacman.conf :
CacheDir = /var/cache/man/pkg/ # first cachedir = where the uncached files will be cached/downloaded
CacheDir = /path/to/repo/ # second cachedir

Sync repository != CacheDir. And the adding of that repo will solve this problem with one caveat- if you run pacman -Sc (or -Scc) you can do a whole lot of damage.

Good point, I completely overlooked the -Sc part. That's too bad, it would have been an easy way, not requiring any code changes :)
I have a bunch of other ideas, probably each being worse than the other...

1) make a distinction in pacman between a primary read/write cachedir and secondary read-only cachedirs
1bis) let the user handle it : if she adds the repo as cachedir to not duplicate files, she should know that -Sc will damage it

2) instead of copying files from file:/ repo to the cachedir, do a symlink instead. This has the usual drawback of file: specific handling : no mtime detection, no good output, no progress bars. Unless we re-implement all of it.
2bis) let the user make a repo-add/repo-remove wrapper to add/remove symlinks from cachedir

I'm closing this old old bug as "won't implement". The reasoning being that the pacman cache should keep a copy of any package that it installs. That was it is available even if the location pointed to by file:// changes. The use can use a -Scc after update if they want - or use a hook.