hoping for a discussion to make it clear why io.Writer and not io.WriteCloser

I would say because the former is enough in almost every scenario. And it's not clear what Close should do, as you say.

If Close does nothing, it would be trivial to wrap Discard in something similar to ioutil.NopCloser. And if Close did do something, I would assume the change would be too drastic to fit in Go1.

Note that whatever the change made is, this could still break programs. Some code may detect if a Writer is a WriteCloser via reflection, for example.

Technically changing the type of ioutil.Discard would break the Go 1 compatibility guarantee. I admit it's hard to imagine that it would break any real program, but that is still a clear drawback, and we need a significant benefit to make such a change. I don't see the significant benefit here; I doubt this comes up all that often, and when it does it's easy enough to write

type DiscardCloser struct {
    ioutil.Discard
}
func (DiscardCloser) Close() error { return nil }

I find that I need a no op closer as often as I need a no op writer. File io patterns are very common.

Just my opinion mind you, but personally "enough in almost every scenario" is never a compelling argument to me even if it were based on a statistical reality. It's just the same as saying it's almost enough. Which is also to say that it isn't.

Further I can't imagine any reasonable logic which isn't already broken that would take a different and conflicting action based on an abstract type bing a WriteCloser and not a Writer. A WriteCloser is by definition also a Writer, while the converse is not. More generally is it not within the language definition that it is 'safe', if not encouraged, to use types with more expansive interfaces than strictly required in a particular context?

Checking if an io.Writer is actually an io.WriteCloser seems like the breaking behavior to me. If I give an io.Writer to a method that calls for an io.Writer, it had damn well not check to see if I have a Close method on the object and do something different based on that information; like, heaven forbid, call Close(). If you ask for an io.Writer you are claiming an io.Writer is all you need.

The real value judgement is not one of convenience vs go 1 breaking change. I don't see any breaking change, and more than convenience the change leads to cleaner more readable code. Having to introduce new, effectively meaningless, types into code substantially reduces readability even in simple cases like this. If one coder fails to name these types something like DiscardCloser, then a reviewer has to go find this type perhaps in another file, just to discover that it doesn't do anything at all.

Just an opposing opinion to the opposing opinions, take it for whatever it's worth.

An example of the way this would be a breaking change is

    d := ioutil.Discard
    var p *ioutil.Writer = &d

That compiles today but would not compile if we made this change.

To be clear, the definition of Discard is:

var Discard io.Writer = devNull(0)

We cannot change the declared type here, as Ian noted. A better answer might be a NopCloserWriter adapter like NopCloser is for Reader. Then you can use NopCloserWriter(Discard).

I guess my other question is

This however cannot be used in scenarios where we need an io.WriteCloser.

Why do you need an io.WriteCloser?

@robpike filed #22823 for NopWriteCloser (or whatever spelling is right). I think we can close this issue, since we clearly can't change the type of Discard.