For vanilla demo specs we have UDS. For Boom and MBF ones there don't appear to be any publicly available docs*, and not everybody can read source code. Even those who can probably don't have it all neatly organized in a table in their heads, I imagine. So here's the first step towards rectifying this situation. Ideally, this should end up as a nice detailed Wiki article. Or maybe two or more, as it would be nice to have an in-depth comparison of technical differences between various complevels.

Here are the results of my amateur research based on empirical testing and supplemented with dipping into Prboom-plus' codebase (the main source being g_game.c). I'm confident that entryway, Quasar, RjY and kb1 would spot any accuracies and fill the gaps the quickest, but contributions from anyone who has delved into the depths of demo (as well as net, savegame, etc.) compatibility are welcome.


General observations

Boom demo header is 109 bytes long and incorporates all of the fields from the post-v1.2 format. It appears to actually use only bytes 0x00 through 0x1A (except for byte 0x11, which appears to be unused by Boom and its derivatives and is explicitly set to zero by *G_WriteOptions), as well as bytes 0x4D-0x50 (players present). The rest is presumably space for future expansion and consists of zeroes.

MBF demo header is in the same format, just replaces the Boom signature with its own. It takes advantage of the unused bytes in the Boom header (starting with 0x1B) to add new fields. Complevels 8 and higher use this format, and Prboom-plus continued to add new fields within this framework.

Nevertheless, the two demo formats are not mutually interchangeable, at least as far as demo playback is concerned.
First, MBF-format demos appear to be using different format for the data section (I suspect it's longtics by default), as merely changing the Boom signature of a -complevel 9 demo to that of MBF and vice versa leads to an almost instant crash with an unknown savegame error.
Second, some unused zero-value bytes in the Boom header have the value of "1" in the MBF header, even when that actually reproduces Boom behavior, e.g. the above-mentioned 0x1B byte (monster_infighting).

I organized the data portion of my findings into three lists, posted separately below for your examination.

* - yes, I'm aware of Mbflmpc. It's old and of very limited functionality - doesn't support Boom demos, drag-n-drop, CMD and doesn't read any of the newer fields.

edit: typo