The short answer is that it's infeasible. It's also I think an error to try. Yes, adjacent calls like this are a bug but the point of locking is to keep someone out. It's not even necessarily an error for the same goroutine to call Lock twice: it could be the job of another one to unlock. This works:

package main

import (
	"fmt"
	"sync"
	"time"
)

func main() {
	var mu sync.Mutex
	go func() { time.Sleep(time.Second); mu.Unlock() }()
	mu.Lock()
	mu.Lock()
	fmt.Println("hi")
}

https://play.golang.org/p/O3pOKFeCkRG

Now that's clearly a ridiculous example but the model of its computation is legitimate: I wait for you to release a resource. All I've done here is release the lock you think is erroneous, but perhaps it's another goroutine's job to do that, and from looking at your code it's really not possible to know that.

You'd need some magical whole-program analysis, possibly even the solution to the halting problem, to know statically when a lock call is erroneous. Even dynamically, I think it's almost impossible to get it right every time.

Unfortunate as deadlocks are, they're just bugs of a different flavor, and need to be debugged using any tool that works. In this case, I don't think vet is the right tool.

but the model of its computation is legitimate

Fair enough.

It's also I think an error to try.

I guess one of the nice things about Go is that it makes it easier to reason about concurrent programs. Being able to detect a case where a thread holds a lock, and is blocked on itself would be really helpful.

Closing but reopen if there's something I'm missing.