Not sure this is the right solution for 2 reasons:

First, I'm uncomfortable with making a package creator's VCS provider part of the language's module infrastructure.

Second, not all files under version control necessarily belong in a tarball, and not all files in a tarball necessarily need to be under version control.

However, the point that there should be an easy way to track changes in your dependencies is well taken. One possible approach would be that publishing a packge boils down to importing the files that normally would go in your tarball into a community-controlled VCS.

> First, I'm uncomfortable with making a package creator's VCS provider part of the language's module infrastructure.

Why can't you store a (possibly shallow) clone of the repository in the "package" registry?

> Second, not all files under version control necessarily belong in a tarball

How likely is it that files under version control but "not belonging in a tarball" (not needed to compile the current version) take so much space to justify making a tarball? At least if you make a shallow clone.

> not all files in a tarball necessarily need to be under version control

Which wouldn't (besides huge files that can be handled with git-lfs and similar)?

If you have configure in mind, let's not do it please.

The risks introduced by including them vastly overcome their convenience, in my opinion.

And maybe let's move towards getting rid of autotools