I'm going to take back the last change because it adds some script before the DOCTYPE line (to early) e.g. on the login page.
Furthermore I have searched through this WP.org forum for an explanation of the "[...] characters of unexpected output during activation. If you notice “headers already sent” [...]"-message. But there are no solutions or explanations for the message, too.
But I have searched for more information about the
error/warning/notice: array ( 'type' => 2048, 'message' => 'is_a(): Deprecated. Please use the instanceof operator', 'file' => '/usr/www/users/myusername/wp/wp-includes/script-loader.php', 'line' => 582, ) | length: 2533
message.
The explanation of the message type (2048) suggests that the message is more a like suggestion than a report of a system breaking error. That is probably the reason why WP does not stop the activation of the plugin and says "[...] If you notice “headers already sent” messages [...]" do something.
I have also tried define('WP_DEBUG', true); in the wp-config.php and set error_reporting(E_ALL | E_STRICT); to see all PHP message. But I still could not reproduce the messages you have posted above.
The only messages I have recieved while having set these error reporting settings were messages about some things in the WP source code itself which I could fix with small changes in the WP code. (No other plugins have been active during the de-/reactivating of podPress)
WordPress itself produces with define('WP_DEBUG', true); PHP Notices which can cause "Warning: Cannot modify header information" messages and break the page. For instance on the plugins page: I get in the debug mode always the notice "Notice: Undefined index: plugins in H:\xampp\htdocs\wp30mu\wp-admin\plugins.php on line 16" (whether plugins are activated or not). But this notice is only a notice for the developers which says basically that this line is a little bit sloppy $menu_perms['plugins'] is obviously not defined at this point of code execution:
line 16:
else if ( $menu_perms['plugins'] != 1 && is_super_admin() )
and with
else if ( isset($menu_perms['plugins']) && 1 != $menu_perms['plugins'] && is_super_admin() )
you can prevent the notice. isset() checks first whether the variable is defined.
But it is only a notice and the PHP interpreter can handle the "sloppy" line, too. That why WP works without problems while WP_DEBUG is not defined or defined as FALSE.
On the other hand the output of this notice can break the page on activation of a plugin because this notice is put out at a wrong moment during the page loading process and causes these "Warning: Cannot modify header " warnings.
What I want to say is that you can should follow the WP message: "[...] If you notice “headers already sent” messages, problems with syndication feeds or other issues,[...]" report these messages which are probably "real" error messages here. But if you do not recognize such other messages you can use podPress.
You could also review your error_reporting settings. They are eventually a little bit to strict for the normal usage.
In normal blogs I set define('WP_DEBUG', false); and error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_USER_DEPRECATED (resp. error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_USER_DEPRECATED);)
Or that this warning is caused under influence of another plugin.
Have you tried to deactivate all plugins and reactivate only podPress?
Does one of the messages appear?