Responding to some of the issues raised
Push vs. Pull
When it gets right down to it, it's really all pushing for the developer and all pulling for the tracking site. The question for the tracking site is whether or not they want to use an interrupt pull or a (sorry about this . . . :-) poll pull. If I had a tracking site, what I would be inclined to do is, after accepting the initial SPIF submission, send an email with a URL in it that would easily allow the developer to click on it and force the update. In addition to being hard on the servers, I don't see polling as being particular desired by the developers; is anyone really willing to wait even a day before telling someone about their new software?
I left an attribute for changes off because, to be honest, I really don't use it (same thing goes for dependency information). Logically, if I'm a new user of a piece of software, I care more about the descriptions of what the software is and how it is useful to me than what has been changed (i.e., I have no basis for evaluating the changes). If I'm a current user of a piece of software, just knowing that it has been updated is usually enough for me to either download it or read the updated documentation, or do nothing initially if I'm happy with the way this version is performing.
But I do agree that it would be handy to have in the SPIF file itself. I like the suggested changelog/change suggestion, an I'll add it to the SPIF document as a proposal. Dependency information probably needs more discussion as to what you actually refer to as the dependency (I'd be inclined to go with a SPIF URL).
Site requirements/corrections, invalid submissions, etc.
I fully expect sites to apply whatever standards verification they have on the submitted file, just as they would on a submitted form page. If the submission has problems, the developer gets a response from the web server (or an email if your server is actually doing polling) telling them to fix their damn file! If it's accepted but there is manual correction that needs to be done by site staff, I'd have the developer emailed those updates so that they can fix their file for the next submission. The tracking site is absolutely free to not accept problem SPIF URLs if the developer refuses to make corrections.
Conflicting site requirements
While this can become an issue in theory, I don't see it becoming one in practice. The SPIF format should be flexible enough to accommodate various site. If you come across an attribute you don't like, just ignore it. The category attribute list is one such example. The site simply goes through the list (considering it a hierarchy, if necessary) until it can match a listed category with a site category, and rejects the submission if there isn't one. The developer is free to put site-specific categories on that list without it affecting other sites. Hopefully all attributes can be so flexible (if necessary).
Some are rightly concerned about the file format, and others have correctly noted that it's pretty easy to map between formats. The most important thing to me is that tracking sites start accepting submissions with some kind of non-manual entry. Ideally, we can work out a base format that is easy to parse and either use directly or convert to other formats. If you don't like the plist format or think XML (even a proper DTD) is overkill, it can be something flatter like:
author/name Subsume Technologies, Inc.
What's important is that it contains sufficient information. I think we're getting there, so it comes down to finding a base format that is expressive enough and easy enough to work with. I have no particular preference of my own. So my question to tracker sites like freshmeat and the developers who submit software is what kind of format are you willing to work with?