@rachelandrew and @mrego found some problems with the spec for fit-content() and its interaction with stretch content alignment of the tracks:

So I thought this was a clear issue and I've already a patch for it. But now reading the specs I'm not 100% sure, so let's clarify this before landing the patch.
The relevant sections of the spec are:

• 11.8. Stretch auto Tracks (https://drafts.csswg.org/css-grid/#algo-stretch)
  This step sizes expands tracks that have an auto max track sizing function by dividing any remaining positive, definite free space equally amongst them.
• fit-content( ) (https://drafts.csswg.org/css-grid/#valdef-grid-template-columns-fit-content)
  Represents the formula min(max-content, max(auto, argument)), which is calculated similar to auto (i.e. minmax(auto, max-content)), except that the track size is clamped at argument if it is greater than the auto minimum.

The max track sizing function for the fit-content() tracks is "max(auto, argument)".
In the case "auto" is the maximum should it be considered an "auto max track sizing function" or not?

Would be ok to avoid stretching in all cases? Should we stretch any of them?

IMHO, I believe that we should avoid stretching for fit-content(). That would be simpler to implement too. But I'd love to hear the feedback from Rachel and Tab on the topic. Thanks!

When we wrote the spec for fit-content(), the auto in the formula was intended as a replacement for the min-content argument of the shrink-to-fit formula, as is made clear in the parenthetical “(i.e. minmax(auto, max-content))”. Removing the word auto and substituting the parenthetical in its place makes the intended behavior much clearer.

However, there is a remaining question: should that max-content argument actually be auto, i.e. respond to stretching (which is the only difference between auto maximums and max-content maximums)? It would still be clamped by the argument as Rachel requests, since once the track hits that limit it should be treated as a fixed-size track:

For this purpose, ''fit-content()'' tracks are treated as ''max-content'' until they reach the limit specified as the ''fit-content()'' argument, after which they are treated as having a fixed sizing function of that argument.

I'm leaning towards yes, since having fit-content() behave exactly like auto aside from clamping at its argument seems like a useful and friendly behavior, but other thoughts welcome~