Note that I don't think this has anything to do with vendoring as such. It's a problem with the compiler error message.

This is unrelated to vendoring. This happens if you just have two packages x/y and z/y that define different y.T's.

Here is a shorter example:

package main

import (
    t1 "html/template"
    t2 "text/template"
)

func main() {
    var x interface{}
    x = new(t1.Template)
    println(x.(*t2.Template))
}

$ go run x.go
panic: interface conversion: interface {} is *template.Template, not *template.Template

goroutine 1 [running]:
main.main()
    /tmp/x.go:11 +0x97
exit status 2

99% of the time you do want to see the shortened name. And in general reconstructing an expanded name may be difficult. For example the type involved might actually be func(chan *template.Template). Rebuilding that entire string with the expanded package name, from within the runtime, is non-trivial.

That's not to say we shouldn't do it, just that it's actually hard.

In #17283, we had discussed changing the error to something like:

interface is foo.Bar (x/y/z), not foo.Baz (a/b/c)

but we were only considering the case of bare declared types. This solution doesn't extend to compound type literals though that might contain multiple declared types.

It's also not clear that it's always appropriate for single declared types. For example, expanding func(chan *template.Template) as func(chan *template.Template) (text/template) might be confusing because the (text/template) almost looks like a return parameter signature.