/cc @bcmills @rsc to see if we actually want to do this.

Personally, I'm not a big fan of alignment like that. it messes up diffs - what would be a single-line addition or removal of a dependency becomes a change to every line with a // indirect comment on.

Also, hopefully, we'll see many less // indirect comments as time goes on and more and more repositories get go.mod files, so this will become less of an issue over time.

Also, hopefully, we'll see many less // indirect comments as time goes on and more and more repositories get go.mod files, so this will become less of an issue over time.

It is appear to be acceptable.
Thx

As @rogpeppe notes, // indirect requirements should decrease over time.

(It's true that alignment add spurious diffs, but arguably diff -b — a.k.a. diff --ignore-space-change is a good default for Go development anyway, given gofmt.)

FWIW: This does not only affect modules or "indirect" comments but in general all kinds of enumeration:

Before:

func notAnElementName(name string) bool {    
	return strings.HasSuffix(name, ",attr") ||  // names an attribute    
	       strings.HasSuffix(name, ",chardata") // not actually a name    
}

(first comment aligned by one space; second line indented by 1 tab and aligned by 7 spaces)

After:

func notAnElementName(name string) bool {
	return strings.HasSuffix(name, ",attr") || // names an attribute
		strings.HasSuffix(name, ",chardata") // not actually a name
}

(second line indented by 2 tabs; no alignment)

Now that's just two lines, but every other year one might have to handle a dozen+. Lack of alignment really hurts here. Struct tags do get alignment, so apparently someone had the same idea.
(... Of course, in the general case one probably does not want comments on adjacent lines to align - namely if the comments are not actually related.)

@Zsar that sounds like it should be a separate issue; the syntax and formatting of .go and .mod files are not related, even if they can look similar at times.

I'm not sure if there's a benefit here for go.mod files.

Since this issue was created we've separated out indirects into their own section in the go.mod file. (#45965) We did that when we introduced module pruning (which increased the number of indirects)