Yes, there are several aspects of a full transfer that aren't reported properly
in dry-run mode. In this instance the symlink happens to point to a directory
where up-to-date files exist, so rsync is fooled into believing that they won't
be transferred. To fix this, rsync will need to keep track of invalidated path
prefixes that cause files below them to be marked as not existing. Something to
look into fixing at some point in the future, along with bug 1433 and bug 1764.

This is now fixed in the CVS version. It became very easy to fix after some
recent changes I made provided the hierarchical depth value for each file, which
means that anytime a directory is missing in --dry-run mode, we just need to
ignore all items that are deeper in the list up to the next item that is
less-than or equal-to the missing depth.
Note that there is a potential for the incorrect output to occur when talking to
an older rsync (prior to protocol 29). This is because the sort algorithm in
earlier rsyncs might put an item from outside a directory's hierarchy in between
the directory and its contents. To see this in action, update to the CVS
version (also available in the latest "nightly" tar file), add a file named
"projects.txt" in the "a" dir of the above test-case, and verify that the
--dry-run output works properly. Then, repeat the test with the debug option
"--protocol=28" and the items inside the projects dir will not be listed in
--dry-run mode (because projects.txt sorted in between the dir and its contents).