Unfortunately the production environment is very controlled and we won't be able to remote debug over there.

But yes, theoretically we know which server is corrupted, we added a firewall rule to disclose the server name on demand through a dedicated querystring param.

Also, as Andrew noted, it does not seem related to web farming sync nor output caching, because the problem is still there with those 2 features disabled.

I will try to patch the instance tomorrow with an updated DotNetNuke.dll, but if it does not work, we're left with restoring, and trying to reproduce in dev or pre-production, which we haven't been able to do yet.

We finally isolated the problem as that reported issue with a 3rd party sitemap handler.

It is still unknown how exactly that specific provider can break the instance, but there's probably a connection to your problem, Andrew, if caused by a distinct component.

I will investigate and let you know about the underlying bug.

First, I want to thank everyone for their help and offers to do so.

Jesse, I'm sorry but somehow I missed your awesome offer to help me remotely.

In the end I found the issue, along with another I found on another site. I haven't looked to deep into the core code, but it seems that variables using cache have become references to the cache instead of instances of it.

The custom module in this case does modify the endDate of the module during the page init event. In versions prior to  7.4 the value would be over written with values from the cache if the page was reloaded. It seems that has changed. When I change the endDate, it actually changes the cache to that value too.