I've run into this type of problem in several different places before, and I think it's indicative of a more general problem with the interface system. One example that comes to mind is in the implementation of the scripting language I'm working on. There are a number of types that are used to wrap other types to provide extra functionality, such as a Lambda getting wrapped in a Memo to provide automatic memoization. Both the original type and the wrapper implement the same interface, and this interface is used to abstract away which is actually being used, a la subtype polymorphism/dependency injection. The problem is when I want to expose optional extra functionality provided by the inner type. For example, both ScopedFunc and Array implement Func, and Array also implements Lenner. Once I've wrapped an Array, abstracted behind a Func, inside a ScopedFunc, though, the ability to use Lenner's functionality disappears. In other words,

type Func interface { /* ... */ }
type Lenner interface { /* ... */ }

type Array []Func // Implements both Func and Lenner.
type ScopedFunc struct { Inner Func } // Implements Func.

var sf Func = &ScopedFunc{ Inner: Array{} }

// Users of sf have no way to cleanly get access to the Lenner functionality of sf.Inner's actual value.

Maybe this is something that could be solved by generics.

It's fairly easy to wrap MultiWriter to do this.

See: https://play.golang.org/p/fbst3OOSVyk

If you are doing this, you should probably also consider Flush, but that can be handled in a similar manner.

That said, a general rule for helpers like MultiWriter and TeeReader is that, if you're creating them, you're responsible for dealing with the readers/writers they were created from.

As noted in #27617 (comment):

Taken to the logical extreme, though, that pattern would either require compile-time metaprogramming or result in an explosion of […] implementations: there are other methods […] that could/should be supported, and for n orthogonal wrappers we currently need 2ⁿ wrappers.¹

¹ See, for example, this experience report.

There doesn't seem to be a good reason to change io.MultiWriter. Perhaps we could add io.MultiWriteCloser, which would not have to wait for Go 2. Better still might be to create that outside of the standard library and see whether people choose to use it.