From Automatic Box Type Transformations,

For legacy reasons, if an inline flow-root box (aka inline-block) is blockified, it becomes a block box (losing its flow-root nature)

At first I thought this was acceptable because all current features that blockify also force block containers to establish a BFC, and thus the flow-root nature is not really lost in practice.

However, in #2673 it was resolved that blockifications and establishing FC are independent. This means that a future feature which only blockifies would make inline flow-root and run-in flow-root end up generating a block container with no BFC. This would be bad, and would force authors to continue using hacks like overflow: hidden to ensure that the element establishes a BFC.

For inline-block it's necessary to blockify to block due to backwards compatibility, and this is acceptable, but if the author explicitly uses flow-root, then this shouldn't be lost.

Therefore, I'm asking for a reconsideration of the resolution reversal from #1496 (comment) in favor of the original resolution from #1246 (comment)

Current behavior: (blockifications in blue, inlinifications in green)

Unaliasing inline-block and inline flow-root,

However, instead of treating inline-block as an exception, it may make more sense to separate the flow inner display type into two:

Intuitively, the two extra values in the 3x3 grid would be

• A block container with no forced BFC, like block, but which inlinifies to an inline box.
• A run-in block container, like run-in flow-root, but which blockifies to a block container with no forced BFC.

Currently there may not be enough use-cases to syntactically allow these combinations, but it could be beneficial to leave the door open to add them in the future.