Same with MySQL 5.7.
My guess is it's actually by design, but is wrongly documented in MySQL manual.

The manual says:

As of MySQL 5.7.9, the default row format is defined by innodb_default_row_format, which has a default setting of DYNAMIC. The default row format is used when the ROW_FORMAT option is not defined or when ROW_FORMAT=DEFAULT is used.

That is, it does not cover the case with ROW_FORMAT=FIXED.
This case is described separately in the manual:

ROW_FORMAT=FIXED is not supported. If ROW_FORMAT=FIXED is specified while innodb_strict_mode is disabled, InnoDB issues a warning and assumes ROW_FORMAT=COMPACT.

Of course, it's wrong. I think they forgot to change it when they changed the "favorit" format from COMPACT to DYNAMIC, but the idea probably remains – if ROW_FORMAT=FIXED is specified, it's not the default that is applied, but a specific replacement – COMPACT in 5.6, DYNAMIC in 5.7.

Of course, it's me reading between the lines, so I'll assign it to jplindst for the expert opinion.

I think that we should file this as a MySQL documentation bug. The implemented behaviour makes sense.
There should be no benefit of using ROW_FORMAT=COMPACT instead of ROW_FORMAT=DYNAMIC.
Full disclosure: I designed and wrote the initial implementation of WL#8307 in MySQL 5.7.

The upstream documentation issue has been filed as http://bugs.mysql.com/bug.php?id=84006.

greenman, if you think there is a place to document it on our side as well, please do; otherwise, it can be closed in any way you like.

I have documented this case in detail on the CREATE TABLE page, so will close this issue for now. I still think this behaviour doesn't make sense, as perhaps a user is wanting to use COMPACT for compatibility reasons, and unexpectedly creating a DYNAMIC table, a format they've explicitly moved away from, is odd.

I am the author of ROW_FORMAT=COMPACT in MySQL 5.0.3 and ROW_FORMAT=DYNAMIC and ROW_FORMAT=COMPRESSED in the InnoDB Plugin for MySQL 5.1.

Ian Gilfillan, compatibility with what? MySQL versions older than 5.6 do not really support importing *.ibd files. In InnoDB, ROW_FORMAT=DYNAMIC is almost the same as ROW_FORMAT=COMPACT, with the difference that long columns that are stored off-page will be stored completely off-page, without a local 768-byte prefix in the clustered index leaf page. In MySQL 5.1, the InnoDB Plugin introduced support for ROW_FORMAT=DYNAMIC, but the built-in InnoDB does not support it. In MySQL 5.5 (which the earliest versions of MariaDB is based on), ROW_FORMAT=DYNAMIC is supported.

I do not see much reason for the ROW_FORMAT=COMPACT to exist at all. Maybe some future version of MariaDB could take the step of treating COMPACT and DYNAMIC the same (never store a BLOB prefix locally). This would of course require tagging the *.ibd file in some way that prevents import into earlier versions.

That's more of an argument for doing away with the innodb_default_row_format variable altogether. I don't know if it's ever useful to set it, or whether there can never be any consequences to having an unexpected mix of DYNAMIC and COMPACT/REDUNDANT, but the variable exists, and if someone did set it, they'd probably expect it to apply in this case. But then it's such an extreme edge case (they do all the above, and then mistakenly specify FIXED when creating), as long as it's documented I'm happy.

Someone could want to use ROW_FORMAT=REDUNDANT (the original InnoDB format) instead of ROW_FORMAT=DYNAMIC. There are clear differences between those two. ROW_FORMAT=REDUNDANT records can be parsed without having access to the index definition, so using that format may increase data file size and reduce redo log volume and speed up operations.

I would say that the treatment of ROW_FORMAT=FIXED is a borderline case. In non-strict mode, InnoDB is interpreting an invalid value as some valid value. We can see what upstream does. I would guess that they would treat it as a documentation bug rather than modifying the code in a GA version.