When p doesn't contain $ANYVERSION then the result shouldn't call package. This allows us to write a model for v1 of github.com/a/b which doesn't apply for github.com/a/b/v2, for example.

Context:
When the go package github.com/a/b/c/d , which is in the go module defined by github.com/a/b/go.mod, upgrades from v1 to v2 then its import path becomes github.com/a/b/v2/c/d, or equivalently github.com/a/b.v2/c/d. In the go codebase we have a predicate package(string mod, string path) which deals with this, so that package("github.com/a/b", "c/d") will match both of those import paths (and v3, v4, and so on). This is so that when a package we have modelled releases a new version, our models already work for that new version.

The vast majority of the time this is what we want. When we actually want different models for different versions of a package then we have to specify the package path without using package().

One exception to the convention of using package is for standard library packages, because we didn't expect there to ever be a v2 of them. (In fact v2 of the math/rand library is coming out in the next release.)

For MaD we have to put github.com/a/b/$ANYVERSION/c/d to achieve the same result.

Looking closely at the function for interpreting the package string from MaD, I see that for github.com/a/b it gives package("github.com/a/b", ""), so it would also match github.com/a/b/v2). In the situation that both of those exist, it wouldn't be possible to use MaD to model v1 but not v2. It seems to me like we should change the predicate to instead give github.com/a/b in that situation. The downside is that we ought to put $ANYVERSION in almost every MaD package column, which is quite ugly. On the other hand, when there is a non-trivial path, we will have to put $ANYVERSION in anyway, so it might be easier if we have it in almost all cases.