I argue that we should have Parse ignore the monotonic measurements since there is already existing code that assumes that time.Parse("2006-01-02 15:04:05.999999999 -0700 MST", myTime.String()) should work.

The initial report is misleading. The full docs for time.Time.String say:

func (t Time) String() string
    String returns the time formatted using the format string

    "2006-01-02 15:04:05.999999999 -0700 MST"

    If the time has a monotonic clock reading, the returned string includes a
    final field "m=±<value>", where value is the monotonic clock reading
    formatted as a decimal number of seconds.

Are you aware of anyone round-tripping the output of String in production code? I am not. It's a mistake anyway since the String output gives the time zone twice, the second one will override the first one, and it's the less specific of the two.

If there are widespread production uses of String output being fed into time.Parse, let me know.

Otherwise, if someone wants to add to the end of the doc comment that

The returned string is meant for debugging; for a stable serialized representation,
use t.MarshalText, t.MarshalBinary, or t.Format with an explicit format string.

that's fine.

CL https://golang.org/cl/47552 mentions this issue.

SGTM. It was an assumption made by several tests. Fixing them will be easy.