Yes, it is my understanding that one of the major, inviolable design goals in this is not to break any old behaviour, or any such (yes, totally distasteful) "hacks" dependent on it. Now that particular old behaviour is "isolated" under the `display-inside: flow` formatting context, which has to remain the default.

Lets go back to the spec draft:

----

https://drafts.csswg.org/css-display/#propdef-display

> The display property defines box’s display type, which consists of the two basic qualities of how an element generates boxes:

> * the inner display type, which defines [...] the kind of formatting context it generates, dictating how its descendant boxes are laid out.

> * the outer display type, which dictates how the box participates in its parent formatting context.

...

> <display-inside> = flow | flow-root | table | flex ...

> <display-outside> = block | inline | ...

----

It's not just the reframing into `display-inside` (how to lay out children) and `display-outside` (how to participate in parent) which addresses your problem -- that just provides a new way to specify the same behaviour as before. Split into 2 orthogonal axes, cleanly leaving room for new behaviour to exist in combination with old behaviour.

But, rather, it's that plus the specific provision of `display-inside: flex`, within this new framing, which addresses your problem.

If you stick with `display-inside: flow` in your examples of things that are problems, of course nothing is going to change, because that specifically specifies "behave like you always used to".

I'm honestly not sure I understand your complaint. I'm definitely open to the possibility that this is an internally-inconsistent or short-sighted solution, but I'm not seeing it here.