The spec doesn't really define masonry-auto-flow: definite-first, but has the text:

First, picking definite items first for placement can be inhibited by specifying the ordered keyword so that a plain order-modified document order is used instead.

This seems to imply that definite-first causes all the masonry items with a definite track to be placed first, at the "top" of the masonry, and then all the rest of the masonry items flow in. I think it also implies that definite-first is the default value, chosen when you don't specify either keyword (including in the initial value).

I think the reasoning here is that Grid places definite items first, before auto-flowing items, and so Masonry is just matching that default behavior. But that's not really true - Grid's placement algo has four categories of items (fully definite, row-definite, column-definite, and fully auto), and treats each category differently. It places fully definite first, then auto-flows the row-definite items into their chosen row, then just auto-flows the column-definite and fully auto items all together, with column-definite just setting the cursor to its chosen column (possibly advancing the cursor to the next row, if needed).

Fully-definite and row-definite are placed early solely to avoid overlap; otherwise, it's trivial for auto-placement to accidentally fill the areas those items wanted to occupy. Outside of that constraint, tho, they're auto-flowed in order as much as possible (which is why column-definite items aren't re-ordered at all).

I believe Masonry items are most similar to a column-definite grid item - they want a particular column, but are fine with being bumped to a later "row" if needed. They should be auto-flowed with all the other items by default.

This also allows for the potentially useful behavior of having "clearing" items that span all the tracks, and guarantee that following items show up below them. This is useful in Multicol, and I anticipate it being similarly useful in Masonry.

I think it would be acceptable to just make ordered the default, rather than definite-first, if there were good reasons to still keep definite-first around. I... can't think of any, tho. If people do want to reorder some items to the front of the masonry, the order property makes that trivial already. Do we have reasonable use-cases for wanting the definite-first behavior, enough to justify it as a keyword?

(If we did drop it, and we potentially dropped next as suggested in #9988 and #10232, then we wouldn't actually have any choices left and could drop the property entirely.)