You are correct. If you are POSTing a collection, the collection itself is the resource. So if the collection resource was created, you'd return a 201. If it was accepted but not fully processed, you'd return a 202.
If you are implementing parts of the resource on the server with multiple files and there are already existing files that get in the way of a successful POST, you'd return a 409 and not create the collection resource and fail the whole operation. From the REST perspective, it's an atomic operation.
If, on the other hand, you were to support a PUT operation for this resource, you have to support idempotency. So one behavior might be to simply replace any files that were existing as part of the resource with what's being included with the PUT body. You could consider doing this as well for a POST, but that will only work if the existing file names belong to at most one collection resource. Otherwise you might end up trashing someone else's collection.