This is a somewhat meta issue surrounding the current definition of how intrinsic track sizing works, and the intrinsic sizing of the masonry grid.

As currently defined (https://drafts.csswg.org/css-grid-3/#track-sizing) the tracks that have min-content, max-content, fit-content, and auto don't work as they do in regular grid. For most of the tracks the content based tracks will resolve to zero, and the auto will result to 1fr?

On top of this it means that an intrinsically sized masonry grid won't match developer expectations, e.g. width: max-content or similar (being a flex-item, grid-item, floating, etc, etc).
We currently have a similar issue for multi-line flexbox which we are trying to fix, but this is somewhat worse due to being the default.

There are multiple avenues to solving the above, however one would be make masonry its own display type with a reduced subset of allowable definitions for tracks.
Most masonry examples I've seen choose to size all the tracks the same size. An potential path forward would to allow repeats of "intrinsic" tracks where everything gets sizing as-if it was in one track, then decide how many tracks to insert.
On top of this you could additionally allow non-intrinsic tracks in combination with the repeater. E.g.
masonry-tracks: 100px repeat(auto-fill, minmax(min-content, 100px));

Edit - a simple example of intrinsic sizing:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=11094