AUTO_INCREMENT requires a value when inserting, but only sometimes

I am using MySQL (Percona 5.5.34-32.0) and I have this table;

mysql> SHOW CREATE TABLE privmsgs\G
*************************** 1. row ***************************
       Table: privmsgs
Create Table: CREATE TABLE `privmsgs` (
  `msg_id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT,
  `root_level` mediumint(8) unsigned NOT NULL DEFAULT '0',
  `author_id` mediumint(8) unsigned NOT NULL DEFAULT '0',
  `icon_id` mediumint(8) unsigned NOT NULL DEFAULT '0',
  `author_ip` varchar(40) COLLATE utf8_bin NOT NULL DEFAULT '',
  `message_time` int(11) unsigned NOT NULL DEFAULT '0',
  `enable_bbcode` tinyint(1) unsigned NOT NULL DEFAULT '1',
  `enable_smilies` tinyint(1) unsigned NOT NULL DEFAULT '1',
  `enable_magic_url` tinyint(1) unsigned NOT NULL DEFAULT '1',
  `enable_sig` tinyint(1) unsigned NOT NULL DEFAULT '1',
  `message_subject` varchar(255) COLLATE utf8_bin NOT NULL DEFAULT '',
  `message_text` mediumtext COLLATE utf8_bin NOT NULL,
  `message_edit_reason` varchar(255) COLLATE utf8_bin NOT NULL DEFAULT '',
  `message_edit_user` mediumint(8) unsigned NOT NULL DEFAULT '0',
  `message_attachment` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `bbcode_bitfield` varchar(255) COLLATE utf8_bin NOT NULL DEFAULT '',
  `bbcode_uid` varchar(8) COLLATE utf8_bin NOT NULL DEFAULT '',
  `message_edit_time` int(11) unsigned NOT NULL DEFAULT '0',
  `message_edit_count` smallint(4) unsigned NOT NULL DEFAULT '0',
  `to_address` text COLLATE utf8_bin NOT NULL,
  `bcc_address` text COLLATE utf8_bin NOT NULL,
  PRIMARY KEY (`msg_id`),
  KEY `author_ip` (`author_ip`),
  KEY `message_time` (`message_time`),
  KEY `author_id` (`author_id`),
  KEY `root_level` (`root_level`)
) ENGINE=InnoDB AUTO_INCREMENT=5238652 DEFAULT CHARSET=utf8 COLLATE=utf8_bin ROW_FORMAT=COMPACT

I have this modes enabled for the whole session:

mysql> SELECT @@session.sql_mode\G
*************************** 1. row ***************************
@@session.sql_mode: ONLY_FULL_GROUP_BY,NO_AUTO_VALUE_ON_ZERO,
STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,
ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

When I try to insert something, this happens:

mysql> INSERT INTO privmsgs
    ->   (root_level, author_id, icon_id, author_ip, message_time,
    ->    enable_bbcode, enable_smilies, enable_magic_url, enable_sig,
    ->    message_subject, message_text, message_attachment, bbcode_bitfield,
    ->    bbcode_uid, to_address, bcc_address)
    -> VALUES
    ->   (0, 12345, 0, '127.0.0.0', 123456789, 1, 1, 0, 0, 'test',
    ->    'testing message', 0, '', 'xxx', 'u_12345', '');
ERROR 1364 (HY000): Field 'msg_id' doesn't have a default value

The weirdest thing is that if I create another table running the exact same output of SHOW CREATE TABLE privmsgs that I pasted before (but obviously changing its name to something else, like privmsgs2), I can run the exact same query without any errors or warnings:

mysql> INSERT INTO privmsgs2
    ->   (root_level, author_id, icon_id, author_ip, message_time,
    ->    enable_bbcode, enable_smilies, enable_magic_url, enable_sig,
    ->    message_subject, message_text, message_attachment, bbcode_bitfield,
    ->    bbcode_uid, to_address, bcc_address)
    -> VALUES
    ->   (0, 12345, 0, '127.0.0.0', 123456789, 1, 1, 0, 0, 'test',
    ->    'testing message', 0, '', 'xxx', 'u_12345', '');
Query OK, 1 row affected (0.00 sec)

What is going on?!

Note that disabling STRICT_* modes is not the solution I'm looking for: it's not clean, and the fact that I can run the exact same query on another identical table in the same session suggests (?) that the problem might not be there.

Solution

Okay, here are the facts:

This is the table of a phpBB installation which has been working perfectly for a long time with MySQL Percona.
When connecting, by default the application sets the STRICT_ALL_TABLES and STRICT_TRANS_TABLES modes, and has been doing that for a long time too.
Of all the tables the application uses, this is the only one where the described inconsistent behavior appears.
When creating another table pasting the SHOW CREATE TABLE privmsgs output, the new table didn't show this behavior. When using CREATE TABLE privmsgs2 FROM privmsgs, it did.
Downgrading to Oracle's MySQL 5.5.31 didn't change any of these facts.

I tried reconstructing the table with ALTER TABLE privmsgs ENGINE=InnoDB, according official documentation, but that didn't help.

So I dumped the table with mysqldump databasename privmsgs > table.sql, changed its name to privmsgs2 in the file with sed and then reimported it with mysql databasename < table.sql. Then I dropped privmsgs and renamed privmsgs2 to privmsgs.

Then it started working perfectly again. I don't understand why and couldn't find any other reference to this behavior. If somebody is able to explain it with a more precise answer than mine, please do it and I'll accept your answer.