Sorry about this, and thanks for putting up the heads-up here. I wish I had been able to push out a fix sooner, but WP 3.1.3 was released while I was on a week-long house-hunting trip. Argh.
Anyway. The good news is that this problem should now be fixed (or worked around, depending on your perspective) in the most recent version of FeedWordPress (v. 2011.0531), now available at feedwordpress.radgeek.com.
The rest is some technical details.
For those who are curious, the reason that this issue arose is that the most recent release of WordPress added a URL-check filtering function for post guids. Or, rather, it applies an existing filter -- esc_url_raw() -- to a field that it hadn't previously been applied to -- the guid. That filter rejects any URI that doesn't begin with a protocol/scheme that's on a hardcoded whitelist of allowable schemes -- http, ftp, svn, gopher, and a handful of others. Unfortunately, the tag: scheme, used in tag URIs, is not on the list of allowable schemes, and WordPress provides no readily accessible way of extending the list to include it. This is unfortunate since esc_url_raw is now used to filter all incoming guids, and tag: URLs are very commonly used to produce opaque unique identifiers for use in the guid field. So, under the new rules in WP 3.1.3, posts from any source feed that used a tag: URI -- which includes all feeds produced by Blogger, all feeds produced by other Google web services, and a number of other common feed sources, as well as any feeds that don't include explicit guids (since FeedWordPress would generate a guid internally using the tag URI syntax) -- would be inserted into the database with a blank guid, rather than with the guid they were assigned by the feed. This breaks FWP's ability to recognize previously-syndicated posts, and causes the posts to be re-syndicated anew every time FWP checks the feed.
In my view, the failure to include tag: URIs in the list of allowable schemes, and the lack of any way to extend the list to include them, is somewhere in between a flaw and an outright bug in WordPress. Be that as it may, rejected guids are a condition that FWP will have to work around in a reasonable fashion. So the new release of FWP includes a work-around to generate an allowable guid if the guid assigned to the post gets filtered out.
So, again, to fix the issue, hopefully all you should need to do is upgrade to the most recent release of FWP.