...
(First Run) For comm events involving a single consume, we record the cost of that single the successful chosen match as "lower bound". For comm events involving a join, we record the cost of the successful single chosen match for each channel as the "lower bound" cost for that channel. At the end of the first loop all the "lower bound" costs for each entry are calculated.
(Second Run) For comm events involving a single consume, we sum the "lower bound" of other all comm reductions on that channel and say that is the "higher bound". For comm events involving a join, we sum up all the "lower bound" costs of other all comm reductions on that channel and assign that as the "higher bound" cost for that channel. We then sum across all the "higher bound" costs for each channel in the join, and that is the "higher bound" cost for the entire comm event with that join.
Optimizations and Analysis
For any comm event on a channel, the "higher bound" cost will be the same as any other comm event on the channel so if you calculate the "higher bound" cost for one comm event on a channel, you don't have to re-sum for another.
There is the obvious downside that you essentially double pay by having to pay for other comm events on the same channel. However if all comm events in the same block do not happen on the same channel, then the "lower bound" cost is the same as the "higher bound" cost. Furthermore, if the same deployer is the one causing comm events on the same channel, which is often the case, the deployer isn't really double paying for another deployer. In general, this solution works well if we keep blocks small and propose often.