It's confusing that a block container may contain non-block-level things. It's easy to forget that a block container may establish an inline formatting context (this caused #1228, is part of #1457, and in #1550 I even forgot about this just after mentioning it XD). The specs also seem somewhat contradictory about a block container containing only inline-level and establishing a BFC (#1553). It's strange that anonymous block boxes don't become a containing block for their descendants. And I think that whether an element establishes a formatting context of some kind or another or none shouldn't depend on the children. That's because the children may be altered by the parent formatting context (e.g. can be blockified or inlinified), so this kind of behavior does not seem much well-defined in general.

So I propose to do something similar to run-in layout for alll inline-level contents: say that each inline-level sequence is wrapped inside an anonymous box that establishes an inline formatting context.

That "inline-level sequence" could be defined as a maximal non-empty sequence of consecutive siblings starting with zero or more run-in boxes (and intervening white space) followed by zero or more text runs or non-run-in inline-level boxes. (By the way, why are different run-in sequences currently wrapped inside different block boxes? Merging them would simplify this "inline-level sequence" definition).

The anonymous box that establishes the IFC could be a block container. This would imply that only anonymous block containers can establish an IFC. Element-generated block containers would either establish a BFC or integrate the children (which would always be block-level, not inline-level) into the parent BFC. I think this change wouldn't break anything, and would address most issues I mentioned at the beginning, but not all.

Therefore, it might also be interesting to give another name to boxes that establish an IFC, e.g. "inline container". Or the box that establishes the IFC could even be the "root inline box" (but then it would become block-level, so it couldn't be used to explain the strut or other things, see #1551). This would be a bigger change, the new box should be defined somewhere (css-inline?) and other specs might need to be edited with the new terminology. But I think it's worth.