So I can replicate it, and it seems to me like this is a bug in ES. I don't recall this being an issue prior to ES v1.2 being released and we didn't change anything in our code for aggregate activities. ES uses two main DB tables to handle the stream. #__social_stream and #__social_stream_items.

#__social_stream_items includes all activities, while #__social_stream doesn't. If there's an aggregate activity, like submitting multiple photos for a listing, then #__social_stream only has one entry and the 'id' column is referenced in #__social_stream_items.uid for each sub-activity in the aggregate activity.

As an example, upload two photos for a listing. One entry is made in #__social_stream and two in #__social_stream_items and the rows are related via one-to-many relationship #__social_stream.id = #__social_stream_items.uid

My best guess is that ES appears to be aggregating the activities based on the user and not the listing id and so it keeps adding rows #__social_stream_items with the 'uid' column referencing the activity corresponding to the first listing. If we exclude the line below from the ES plugin we have in JReviews, then activities are not aggregated and also not messed up.

Code:
$tmpl->setAggregate(true);

The #__social_stream_items.target_id column is different for different listings as it should be so that's why my best guess is that they are incorrectly using the actor_id.

Please share this post with them and hopefully they have an answer. If we need to change something in our code to make this work in ES v1.2 we can do that. We just need to know where and what.