Just quickly on this point on PuSH, apparently Atom's intended as a bootstrap format, though you and I both know how these things go - once it's burnt into code it's there forever. I'd suggest sharing your concerns with the
pubsubhubbub group who are generally fairly responsive (copying Brett - one of the PuSH "instigators").
I'd like to explore the topic of batches (what we call "collections") a bit more as currently I've sidestepped the issue somewhat by specifying text/uri-list be used to pass a list of resources by reference (sans metadata) rather than by value (e.g. embedded in Atom). This requires O(n+1) requests which isn't great for performance but it works it's easily optimised later.
The question then is how to do it. Ideally HTTP would allow us to request a single resource and have it return multiple responses (that is, full blown HTTP responses, headers and all). Technically this would be fairly straightforward, for example by avoiding parsing for boundaries by using content-length as a delineator for the end of this message (and therefore the start of the next) - but it would require a version bump for HTTP. The IETF boffins claim that collections are done in WebDAV but that's all based on XML and is like taking a sledgehammer to a tack. One can use envelope formats like SOAP or Atom but that's also fairly heavy handed. In any case this is unlikely to happen in our timeframes.
Using MIME isn't a bad idea per se, but it does mean your client not only needs to understand multipart/mixed MIME (and scan for boundaries) but then also needs to be able to decipher each of the message/http contained therein. Many clients include support for the former but not the latter. That said the format is trivial, especially given the alternatives, so this may still be both the path of least resistance and the option that is "closest" to HTTP.
Sam