I'd like to echo an idea that was widely discussed at GopherCon - these large changes tend to attract lots of attention, so the issue threads become unbearably long to the point that they can't be loaded all at once easily.

To expand on @mvdan's point: I think it would be helpful to split the discussion threads for large changes into a main “process and draft updates” issue (with discussion locked) and separate per-topic issues referencing that issue (with discussion unlocked).

For designs with multiple interlocking features, it might also be helpful to split the proposal into separate issues for the overall problem and overall approach and specific sub-proposals that can be adopted or rejected independently.

Some examples:

Main issue: “Interpreting errors is hard. Let's add more structure to the errors package.”
Sub-proposals:

• errors.{Unwrap,Is,As}
• Implement errors.Is for syscall types.
• %w and an error-formatting interface.
• Capturing stack info in fmt and errors.

Or, one closer to me personally:
Main issue: “Overflow is error-prone. Let's make it explicit.”
Sub-proposals:

• Add checked-integer packages.
• Add , ok forms for arithmetic expressions.
• Remove unchecked arithmetic from int.

Or build a slightly fancier version of what Russ made for the try proposal, namely a better presentation layer. Two possible features: (1) Instead of being purely readonly, allow sentiments/votes to be added directly (writing back through to the underlying GitHub issue). (2) Instead of Russ categorizing comments, use hash tags in the comments to organize. When manual categorization is needed, gardeners can edit the comments to add/remove/edit tags.

Another pattern I've noticed for a few large changes (particularly #6977 and #30228) is that the update comments from associated CLs can easily swamp out the discussion thread on GitHub.

It might help to split out a separate tracking issue for associated changes, so the mention-noise can go there instead of to the proposal issue itself.