"A Mergeout operation is already in progress on projection"

Can it be ignored?  That depends on whether mergeout does manage to run the other times that it's kicking off internally.  To determine this, you could check tuple_mover_operations,or more simply, perhaps, verify that the ros_count in projection_storage is not outrageously high. The mergeout process is responsible for collapsing multiple files into fewer/larger files on disk. If that's not happening, you're going to be knocking on ROS pushback's door very soon, and that's not a doorstep you want to be on.

The bigger question is why it seems to be happening so often. I am aware of (valid, and benign) scenarios in which moveout might provoke such an error, but not mergeout. So, it might be worth having our support teams dig a bit deeper into the why of this problem.

Are you doing something out of the ordinary on such a consistent basis that would be provoking mergeout to execute more often than it needs to?

I am also seeing this error message on version vertica-6.1.3-10 in cases where there are more mergeouts threads ( TM maxconcurency  = 4 , plannedconcurrency = 3) and some table is loaded frequently. It appears that mergeout threads are not avoiding ROS containers that are already involved in a mergeout. Is this by design of the product or something else is broken ? 
The mergeouts are completing correctly and the overall ROS count is not increasing alarmingly. 
The reason for having multiple mergeouts is the aggressive ETL process that might hold a single mergeout thread busy for too long .