There are a few reasons why the update of a specific item may fail (e.g., the item has been deleted). The question I'm debating is how to return the result to the caller.
Touchstone: how would you do it as a web page?
Presumably, the user would start out looking at a web page, with a form on it that would allow her to describe the task -- the jobs in the batch. The submit button would POST the form to the resource identified by form.action. The response would be another html page.
Expressed in REST terms, the initial state of the application would be described by a hypermedia document (the html page) with hypermedia controls (links/forms). The application would represent the controls based on its interpretation of the media-type (form parameters). The user would configure and choose which control to activate, which would dispatch a message to a resource on the server, which would respond with another hypermedia document describing the next application state.
That's RMM level 3, anyway. Up to you how much you want to push toward that goal, but I find it's easier to work backwards from "right" to "practical".
I'm leaning towards returning a collection that contains only the items with failures, but I could see scenarios where it would be helpful to return the result for all of them.
Again, how would you handle this with web pages? You'd probably send back the html that is most useful for the common case, and include a link to other resources that describe the result with different granularity. That will get you by in version 1, but eventually you'll discover that some users always prefer the secondary representation. So you'll set up a new resource that accepts the job batch, and returns the secondary representation (probably with a link to the first). Your initial web page would have two links on it, each posting the same batch job to a different resource, so that the user can express their preference for a representation right away, doing away with the extra click.
You can use the same trick with other representations. At RMM-3, your documents would have hypermedia controls to connect the application to other representations of the results, but at RMM-2 you can get by with two different resources that accept the same job batch, and produce different reports.
The key point here is that it is an easy problem to address later, you just add another resource that does the same work.
Assuming that you are using HTTP to transfer your documents back and forth, the right status code is most likely to be 201 (Created). You aren't describing the result of the work in the back end, you are describing what is happening to the resources. Here, you are presumably taking the application that submitted the job to "some representation of the results." Unless you have got time travel going on, the report of the results probably didn't exist before the request arrived at your server, so it is a natural fit that you are creating a new resource (the document describing the results).
It's not, so far as I can see, particularly critical to get this right; returning a 200 (OK) instead is probably fine. I call your attention to it, because I find that thinking about the document helps get past the mental block of confusing the "resource" with the "thing that's actually doing the work".
See: REST in Practice by Jim Webber.