Dll

Since this thread was started in 2015, you may be waiting a while....

There isn't a problem with those pages, as the canonical is set to the correct one on all of them:
<link rel="canonical" href="https://invisioncommunity.com/forums/topic/442742-large-community-you-have-a-problems-with-sitemap/" />  

There isn't a problem with those pages, as the canonical is set to the correct one on all of them:
<link rel="canonical" href="https://invisioncommunity.com/forums/topic/442742-large-community-you-have-a-problems-with-sitemap/" />  

Oh, if you need a Topic\Post, just return the $content then. I thought you needed the topic.

I see your sticking point.
The form is asking for the topic which you are attempting to update the custom data for (which is the stock action I referred to). But unless there is an explicit topic in the event arguments, how could rules give you an option to choose from? In this case, not just topic comments can be reported, but all sorts of other content can be reported. It cannot be assumed that you can derive a topic in from any given piece of reported content. If I report a comment on an image, and that rule event is invoked, how is rules going to get a topic from that comment? It's undefined.
This is why you only have the option to use PHP code to provide the topic for which the stock custom data update action will operate on. Rules knows that it cannot know what topic to use. Therefore you must tell it.
You could put a condition on the rule that checks if the content is an object of the 'IPS\forums\Comment' class, which would ensure the rule only runs when a topic comment is reported. This will prevent errors when other types of content are reported, but you are still left with the need to provide the topic itself for the custom data update action. You need to return the topic from your PHP snippet:
return $content->item();  

@Kevin Carwile, I actually also tried to setup this and when you add the action to update the custom field, the only option for the source is PHP:

I suppose if $content is returned here it should be fine, but I don't know. 

IPS Staff: I hate to say this but the IPS Upgrades are becoming a real inconvenient Annoyance.

What am I talking about? Everytime there is a service update to IPB (2.0.1, 3.0.2, etc) the upgrade creates havok with the hooks that I have installed. Not only do I have to disable the hooks, but, they have to be un-installed and then re-installed. The upgrades are not anticipating already installed hooks and adjusting for them and it's becoming an annoyance.

Does IPS plan on fixing this problem or is this going to be a regular 'romp and stomp' action with every upgrade/update? For one, I would love to see this corrected.