@dsnet, note that the example you cited above is an example of what not to do. From later in that comment:

Ian's #41198 (comment) makes it sound like the answer is "no, ErrTBD is inappropriate in this case; the method should end with return w.Write([]byte(s))". In that case, I'm much more comfortable with the idea and simply agree with Bryan that "not supported" is a better name for the idea than "not implemented". Too many people will think "not implemented" is OK to use in the WriteString example above - the method is, after all, not implemented by w.u.

That would imply that the smallest-diff “correct” implementation for that example is actually:

func (w someStruct) WriteString(s string) (int, error) {
	if u, ok := w.u.(io.StringWriter); ok {
		return u.WriteString(s)
	}
	return io.WriteString(w.u, s)
}

Or, more concisely:

func (w someStruct) WriteString(s string) (int, error) {
	return io.WriteString(w.u, s)
}

[@bcmills I assume youmeant io.WriteString(w.u, s), twice.]

[@dsnet] If we do document that errors.ErrUnsupported is side-effect free, then it also means that this is error prune (pun intended) where returning the error up the call stack increases the probability that there are indeed side-effects from other operations.

...or conversely that an I/O function fails with ErrUnsupported not because the immediate operation was unsupported, but because some distant operation bubbled it up--not unlike the problem of recovering from panics that pass through arbitrary code--after having effects on the state.