This is slightly lower priority than making mongos send the UUID for the final output collection of the second pass, because the final output collection of the first pass is a transient collection.

When we start using UUIDs, in the second pass, we will probably want shards to query the final output collection of the first pass by UUID, which will only work if they all have the same UUID.

It isn't a huge deal if this doesn't get into 3.6, though, because there are no backwards compatibility implications, as this is a UUID for a transient collection that is not meant to be visible to the user. It could be booted into the Collection Lifecycle (PM-85) project.