A few of his observations were correct, and a few were incorrect, so I thought it might help if I shared my understanding of GData's relationship with APP.
First, GData is designed to be a superset of APP. Or more precisely, the intention is to be a fully compliant APP server implementation. The APP working group has done a fantastic job laying a foundation for REST-based document publishing, and the goal of the GData team all along has been to keep pace with the evolution of the specification. (Heck, was it even a question? Google hosted the two-day APP interop session and the GData team flew in from around the world to be there.)
That said, it is worth mentioning that the GData-based services at Google are also among the first large-scale, real-world implementations of APP. Where there are deltas between APP and GData, the differences can be attributed to the fact that the GData services starting shipping back when the specification was in draft 7 or so, and are certainly not divergent by design. The GData team continues to keep the libraries in sync with the APP spec as it progresses, and with the APP spec in last call I expect this to be locked down for good.
There is also a misunderstanding about how "rich" datatypes are supported. The example raised is "how do I use APP to update a Facebook user?" GData chose to use extension elements (called "GData kinds") as a way of explicitly enumerating machine readable data. Nothing wrong with this, of course, as Atom was intentionally designed from the start to support extension elements. (One alternative that I'm fond of is using microformats inside XHTML, but that's neither here nor there.) I think James Snell's idea of POSTing a complete document under a different mime-type is interesting; I'd love to see people explore that more fully. But in any case, those applications are all valid APP.
As people noticed, GData has been using a well known technique called optimistic concurrency to resolve the lost update problem. Nothing technically wrong with this, though we're all keen on ETags as a potential alternative. (The thinking around ETags and APP wasn't nearly as far along when the first GData services shipped.) I wouldn't be surprised if both techniques are used in the future, depending on the needs of the application. Again, both are perfectly valid APP.
I've seen several ideas floated about partial updates. My personal favorite is one that Kyle proposed internally, but I'll wait for the GData team take that one public.
On hierarchy: Yup, this comes up a lot. Atom (the syndication format) deals naturally with lists, not trees. Fortunately it also deals really well with URL-based references, and hence the Atom Threading Extension offers a good way of layering hierarchy on lists. BTW, it's always going to be a trade-off. I love the threading extension myself, and while you didn't hear it here, don't be surprised if you see it in some GData services in the future.
On syncing: Hard problem, no generic solution. No doubt that someday you'll see APP (and GData) services that support syncing. And maybe someday people will figure out the 80% case that mostly works for most applications and we'll write it down and all agree to use it. Until then, expect domain and application specific solutions, and I'm glad that it is orthogonal to the core APP spec. And I'm pretty sure this isn't something missing only from APP. What other document publishing protocols have syncing solved?
In summary:
GData == APP + kinds + token-based auth + search + optimistic concurrencyI expect that this equation will evolve over time as Google ships new code and make improvements, but the one thing I'm sure of is that APP will be the foundation for GData for the foreseeable future.
I'm sorry for the confusion around APP and GData, but I suppose that's natural for a relatively new protocol. The good news is that so many people are already shipping APP-based applications, including some pretty big ones from Google. My sense is that the Atom Publishing Protocol is one of those things that will "just work" and make the web better, just like HTTP and HTML did. Let's not lose sight of that goal, okay?