Since I posted What's still wrong with Atom (and probably will be in 1.0), a few of the issues I mentioned have been resolved. Here's a quick overview of those issues, plus two more. The number of asterisks under each indicates how much I wish the issue would be resolved (1=no big deal, 5=very sad indeed):

1. No "Aggregation" document type
***** Unresolved, and I can't imagine it will be.

2. Ambiguous state of top level child of atom:content when the content is an XML type other than XHTML
* Unresolved, and I can't imagine it will be.

3. No ability to define a Person construct once and refer to it from multiple places within the document
*** Unresolved, and I can't imagine it will be.

4. Feeds and entries must link to an alternate representation of themselves
* Partially fixed: feeds no longer require an alternate. There are still cases where an alternate for an entry is required. I don't expect further change on this issue.

5. Neither feeds nor entries can have more than one author
** Unresolved, and I can't imagine it will be.

6. Entries must contain a summary if they don't have a content element
No longer required.

7. The element for feed logos is named "image"
Changed to "logo".

8. Entries don't have an "image" element
** Unresolved, and I can't imagine it will be.

9. The definition of the atom:link element is too open ended
***** Unresolved, and I can't imagine it will be.

Here are the new issues--I'll number them with the numbers of the resolved issues:

6. No reliable identifier is required for a feed
**** I proposed that either a link to the feed's preferred URL (from which it is retrievable), or an atom:id (for cases where the feed is delivered by some method like email which doesn't have a URL) be required. The proposal was rejected during this last round of discussion. Not having a reliable identifier makes it difficult to match an entry from an aggregated feed up with it's source feed. I have a slim hope that we might find some sort of resolution for this.

7. Multiple atom:entries with the same atom:id in the same feed document MUST be considered the same entry
***** ...which means that if two different entries from two different feeds with identical ids are aggregated into the same feed, one will essentially override the other. This creates an attack vector for people trying to deny access to someone else's entries. I have some hope of us resolving this issue.

Nine issues, four significant, two with some hope of resolution.