According to the changes I made I narrowed the problem to 4 suspects ‘suppossedly’ to be minor:
1-A fix consisting a variable serialization/deserialization to avoid some problems with different PHP installations.
2-A fix to make the plugin relocatable.
3-A fix to call deactivate_plugins on older versions. this code is activated ONLY if we try to install the plugin in a WP version <3.3. I guess we can discard this case.
4-An important side effect affecting multisite plugins. The fix is very simple and I still believe this is not causing the problem, but I can’t discard anything.
So my guesses are options 1 and ‘maybe’ (?) 2 and maybe 4 (?).
While I’m going to make a few round of tests, I have a risky proposition for you, so I understand if you decide to decline it.
What I suggest to solve this riddle is to enable debug and see the error produced when you activate the plugin.
To do that you should insert this line on wp-config.php:
define(‘WP_DEBUG’, true);
and after that try to activate the plugin. That will bring down your site and will display the error. Write it down asap and rename the statcomm plugin folder to reactivate the site (You need FTP access to recover from the problem). That would deactivate the plugin at once and you’ll recover from the error in no time.
It is a wacky proposition , I know.