Confluence (at least as of 4.2.x) does use an id field in the RSS, but this field is still versioned after every edit of the blog post. This causes permanent duplicate entries in Google Reader (which has a global cache).

I have not tested with other readers, but removing the version from the <id> (and thereby keeping the <id> tag the same after an edit) results in Google updating the blog post and does not create a new blog post.

See comments from google here (fourth bullet point): http://support.google.com/reader/answer/69998?hl=en

Comments in /confluence-4.2.13-source/confluence-project/confluence-core/confluence/src/java/com/atlassian/confluence/rss/DefaultFeedBuilder.java

    /**
     * What follows after the ":" in the tag scheme URI spec is called the "specific" component.
     * <p>
     * For versioned content, the syntax is as follows:
     * <blockquote>
     * <code>entityType "-"  latestVersionId "-" currentVersionId</code>
     * </blockquote>
     * When a feed reader downloads the latest version of content, the identifier of this entry should not change.
     * Unfortunately, in Confluence, it does. When the latest version of content is modified, it becomes a historical version and is given a new database id.
     * <p>
     * To address this, we:
     * <ul>
     * <li>use the latest version id to group together versions
     * <li>use the version number to distinguish between versions
     * </ul>
     * 

use the version number to distinguish between versions causes the problem (for me). I've edited this out in the source.

return type + "-" + ((ConfluenceEntityObject) latestVersion).getId(); //+ "-" + currentVersion.getVersion();

We use Atom to create feeds from our own product at Objective Corp. Even though Atom includes disambiguation in the form of a unique id, we found different feed readers do different things with the id.
Some readers treat the same ID as a non-new article, regardless of whether it has been changed since last time the feed was retrieved.
Others ignore the ID, looking only at title and date.
Still others do the right thing and look at ID and date.

We had to solve this basically by optionally allowing the unique ID to incorporate seeds other than the article ID.
Food for thought.

I tested this with your demo confluence (Version: 2.6.1-rc1 Build:#913 Oct 16, 2007).
The duplicate page comments problem seems to be fixed, but the page updates won't show in thunderbird (2.0.0.6) with atom feed. Only the original page. I used only default options in feed builder.
Is the problem in the thunderbird or the feed format?
I have attached screenshots of the problem.

In Confluence 2.6 and later, the title of each entry in the feed is simply the title of the page, comment or blog post, regardless of whether it is created or updated. This is the standard behaviour for feeds, as we understand it.

As I said above, we still don't have an ID in the entry, so there's still the potential for advanced feed readers to think an update is a different article.

Matt,

What is meant by "[t]he issue with entry titles is fixed in Confluence 2.6"? Do you mean Confluence 2.6 now generates new RSS feed entry titles for new edits on the same page or comments added to the same page? If so, what are those titles now?

Thanks,
Mike

The issue with entry titles is fixed in Confluence 2.6.

We don't have a unique ID in the feed yet, but I suspect this will still fix many problems.

I have a bit similar problem with Thunderbird 2.0.0.6. I only get the page edited message once per page (I guess thundebird thinks the new "page edited" item is the same as allready received because there is no id in the feed item and the title is same and so decides to not show it). I get duplicate page comments (see CONF-5256) and it seems to relate to this problem. These two issues makes the feeds totally unusable.

The feeds would be my preferable way to follow the confluence activities. Now I have to periodically manually open the dashboard to see what is happening.