I don't see any ambiguity here. Both + and # are formatting flags and both can be specified. The documentation lists a series of steps "in order of application," so as it says if the value implements the GoString method then the + flag is ignored. Other than that as far as I can see %#v and %#+v only differ if the value implements the Formatter interface, and the Format method pays attention to both Flag('#') and Flag('+').

The question is what happens when the operand implements neither the Formatter or the GoStringer interface; e.g. for an operand of a []string type, can we read from the documentation whether it is supposed to give [hello world] or []string{"hello", "world"}?

I don't see anything that says that the + flag should have any effect on printing a slice. So for a slice with none of the magic methods I would expect that %#v and %+#v would be the same. And that is what I see in practice.

Sorry, I messed up the example at the last minute by trying to substitute a "simpler" one.
Please take a struct with a field of type string for example:

type Link struct { A, Z string }
l := Link{A: "n1:2", Z: "n2:1"}
fmt.Printf("%v\n", l)	// {n1:2 n2:1}
fmt.Printf("%+v\n", l)	// {A:n1:2 Z:n2:1}
fmt.Printf("%#v\n", l)	// pkg.Link{A:"n1:2", Z:"n2:1"}

How do we interpret the documentation to figure out what we get with %#+v?

We could take that the output of %#v should also be fine for that of %#+v for it "adds field names" as well, but I feel it could be rather coincidental than intended. And I was thinking it would be much more straightforward to explicitly mention that + is redundant for struct when # is specified.

%#v for a struct is expected to add field names, since those field names will appear in the "Go-syntax representation of the value.". So it does seem to me that %#v and %#+v should be expected to generate identical output. I don't see how else the read the current docs.

Given that I don't think the docs can be read another way, and given that %#+v is bound to be unusual, I'm not sure it's really helpful to explicitly document its behavior. But I'm open to counter-argument if you can show how the current docs are ambiguous. You said the current docs could be "rather coincidental than intended," and I agree, but I don't think they are ambiguous.

Closing old issues that still have the WaitingForInfo label where enough details to investigate weren't provided. Feel free to leave a comment with more details and we can reopen.