As noted in the sample algorithm for multi-line column flex containers:

If a flex item does not entirely fit on a single page, it will not be paginated in multi-line column flex containers.

Why are items in a multi-line column flex container suggested to be treated as monolithic while the other algorithms do not? For example, shouldn't a fragmented multi-line column flex container with one column behave the same as a fragmented single-line column flex container?

The flex fragmentation spec also mentions:

When a multi-line column flex container breaks, each fragment has its own "stack" of flex lines, just like each fragment of a multi-column container has its own row of column boxes.

To me, this almost implies that a multi-line column flex container will act as a fragmentation context (expect for the fact that items are considered monolithic, as mentioned above). Does it make sense to do the same thing here as a nested multi-column? If we were to instead fragment each flexbox column independently, when stitched back together, the columns would match more closely to the unfragmented result.

Note: neither Gecko or Chromium's implementations of multi-line column flex fragmentation are currently following either of these points in the spec.

cc @mstensho @bfgeek