What's the expected output of formatting:

type User struct {
    Name      string `json:"name" bson:"name" validate:"required"`
    LegalName string `validate:"required" json:"legalName" bson:"legalName" `
    Email     string `bson:"email" validate:"required" json:"email"`
        ....
}

does it reorder the tags as well to achieve alignment?

Under the current proposal, your sample remains unchanged because each field has a single contiguous tag.

If you were to use multiple string fragments,

type User struct {
    Name      string `json:"name"` `bson:"name"` `validate:"required"`
    LegalName string `validate:"required"` `json:"legalName"` `bson:"legalName" `
    Email     string `bson:"email"` `validate:"required"` `json:"email"`
        ....
}

the current proposal would allow it to be formatted as:

type User struct {
    Name      string `json:"name"`         `bson:"name"`         `validate:"required"`
    LegalName string `validate:"required"` `json:"legalName"`    `bson:"legalName" `
    Email     string `bson:"email"`        `validate:"required"` `json:"email"`
        ....
}

(Which is still easier to read than the original, even if not re-arranged into columns.)

The reasons for this are as follows:

• Proposal proposal: cmd/gofmt formatting/alignment of multiple struct tags #16918 was declined because the consensus was that gofmt shouldn't change the contents of strings.
• This proposal departs from the previous by allowing struct field tags be comprised of string fragments: gofmt can format those fragments by inserting whitespace between them while preserving the contents of the strings without change. If gofmt could reorder each tag component, it would effectively be changing the concrete string tag.
• The proposal aims to maintain backward-compatibility with existing APIs by maintaining the field tag concept as a single string.

Having said all that, I wonder whether your example would be frequent in practice:

• When a developer first writes the User struct, they might start without tags, or tags for one key.
• The developer might add additional tags to User in subsequent revisions: as a typist, it is easier and more natural for such edits to append the new key across all fields in the same sitting, maintaining the key-name ordering.
  • For example, when I do this, I typically use VSCode with multiple cursors so that I type out the key:"" part simultaneously for all lines before I fill in the double-quoted text on a line-by-line basis: it's easiest to add multiple carets to the end of each line with a keyboard shortcut than it is to randomly mix them across lines.

Perhaps a more interesting question might be what to do if there are "gaps",

type User struct {
    Name      string `validate:"required"` `json:"name"`      `bson:"name"`      
    LegalName string `validate:"required"` `json:"legalName"` `bson:"legalName"` 
    Email     string                       `json:"email"`     `bson:"email"`     
        ...
}

for which it would be nice arrange the spacing as shown, where possible.

This seems too specialized for gofmt.

It also seems like a separate formatter could do this easily (built with go/parser and go/printer), and gofmt would not get in the way.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group