Good point (also, welcome to the CSSWG, it's great to have you participate).

I find it easier to reason about when thinking about individual elements than with fragmentainers, but it is true that we need to think through the implications on margin collapsing, and that your approach gives an easy way out of that problem. If we end up not taking your suggestion, I think we should be extra careful about what happens to collapsible margins with a different setting.

As for use cases, it seems to me that something like this is reasonable:

h1 {
  margin-top: 5em;
  break-before: right;
  margin-break: keep;
}
h2, hr {
  break-before: always;
  margin-break: discard;
}
@media print { hr { border: none; } }

This preserves a (large) top margin a the beginning of chapters, but drops it at the beginning of subsections (either marked by a lower level heading or by an <hr> element).

We did also resolve to add a margin-trim property which operates on the container, and it seems reasonable to specify that if it is applied to a fragmentainer it applies to margins at breaks at the start/end of the fragmentainer. https://drafts.csswg.org/css-box-3/#margin-trim

Wrt collapsing margins: if margin-break specifies discarding a margin, then all the margins that collapse with it would be discarded. Although I suppose we didn't really specify what happens when some of them are keep and some of them are discard... probably any with discard or auto should be discarded and any with keep should be kept.

CC @dauwhe @MurakamiShinyu @jensimmons @rachelandrew

Actually, nevermind. That comment about collapsed margins is wrong, I was mixing it up with margin-trim. margin-break should operate independently on each margin. Note that all margins that collapse together are adjoining, so if one of them is adjacent to the break then all of them are. There's no order dependence.

I'm not sure how multiple nested elements with collapsing top margins right after a page break should behave if their margin-break values vary.
I will try to put together some graphics to help further explain my issue as soon as time permits.

About margin-trim and fragmentation:
I think that for box-decoration-break: clone applying margin-trim per fragment may be the right approach, but I'm not really sure there.
However, for box-decoration-break: slice I think margin-trim should by applied per element.
But those are mostly my first impressions, I have not gone through use-cases or anything.
BTW, should that be its own issue?

Could you please confirm the following conclusions/assumptions and our reasoning behind them:

1. "Margin collapsing is applied after margin-break." (margin-break affects separate margins while margin collapsing combines them)
2. "Margin collapsing effectively treats all boxes 'truncated' by margin-break like they had a margin-top of 0 specified." ("discard"/"truncate" in the context of margin-break generally means setting the used margin value to 0)

@bernhardf-ro Wrt #3314 (comment) that is my expectation, yes. (Please note this is just a first draft, so nothing is fixed here, we're still accepting comments on how exactly it should work.)

Thanks @fantasai for the confirmation (And belated thanks @frivoal for the warm welcome.)

With collapsing being applied last, I think the implementation side is safe. However, collapsing of nested elements seemingly changing truncated margins to non-zero values may be confusing for some authors. (In my personal experience margin collapsing, as it is, is already considered confusing by quite a few.) This may be solved by considering truncated margins to not be adjacent to any other margins or similar limitations to collapsing.

I still believe the simpler approach, setting the property on the fragmentation container, would eliminate these problems entirely. The desired result in the sample above can be achieved without using margin-break and the CSS would still be compact. And I have failed to come up with any more complex and realistic use-case that requires the finer control. Maybe someone else can.

Would adding properties for both elements and fragment containers, similar to *-self and *-items, be an option? It would provide the advantages of both, at, what seems to me, a very minor increase of complexity.