main.go

package main

import (
	A "github.com/some/package.v1"
	B "github.com/some/package.v2"
	C "github.com/some/package.v3"
)

func main() {
	// Say that, in some part of our program, we call off to something, handing
	// it an int and wanting to get back the square of that int. We store that
	// result in x.
	var x int

	// We start by pulling in some version of this dependent package - let's
	// call it A - which does what we want, correctly.
	x = A.Square(2) // x is 4 here.

	// Now, imagine that the dependent package, for whatever reason, decides that
	// they want to take and return an int64 instead. The operation being performed
	// is still the same - so the *intent* of our program is still met - but we
	// have a type-level error, of the sort static analysis will detect.
	x = B.Square(2)

	// Or, in some alternate timeline, the upstream author changes the
	// implementation itself without changing the interface. The *intent* of our
	// package here is still violated, but don't have a type error, so static
	// analysis cannot catch this. We need some other mechanism for
	// communicating what's gone wrong.
	x = C.Square(2)
}

pkg_a.go

package A

func Square(x int) int {
	return x * x
}

pkg_b.go

package B

func Square(x int64) int64 {
	// Using an int64 instead? Totally valid. And on most computers nowadays, of
	// course, ends up being the same as just an int. But simple static analysis
	// will still declare that this func is "incompatible" with your original
	// implementation based on package A.
	return x * x
}

pkg_c.go

package C

func Square(x int) int {
	// While it's easy to look at this and say, "well duh, that's an incorrect
	// implementation of squaring something - just fix it!", what actually
	// matters here is that the type system, especially Go's type system, is in
	// NO WAY a guarantee that just because the types align, you're getting back
	// what you expect.
	return x + x
}