> pkgname=foo-git; provides=('foo=2.0.r0.g0') # does not work
I dispute this, as it's extremely commonplace. Sure enough, the below PKGBUILDs result in an installable 'bar' after installing 'foo-git':

## foo-git
pkgname=foo-git
pkgver=2.0.r0.g0
pkgrel=1
arch=(any)
provides=("foo=$pkgver")
package() { :; }

## bar
pkgname=bar
pkgver=1
pkgrel=1
arch=(any)
depends=('foo>=2.0')
package() { :; }

Can you provide "complete" PKGBUILDs which show otherwise?

That one seems to work now but it's not very useful as I should not need to explicitly name the version that is already in pkgver.

Debugging this took many hours longer than it should have because for a while the git that produces or updates $srcdir/vcs decided to also reset the PKGBUILD to the AUR4 version on each makepkg run. Once I found the offending line with 'sudo chattr +i PKGBUILD; bash -x makepkg -o' and that it shouldn't be changing PKGBUILD, it took a lot of rapacious folder deleting and temporary PKGBUILD changes to stop git from changing a file referenced in the AUR4 vcs but not the package vcs.

Looks like the version check is working. The unreasonable requirements in provides still need to be fixed. The version checks must be orthogonal or we'll get the impossible version dependencies we see in the forums from time to time.

## foo-git PKGBUILD
pkgrel=1
arch=(any)
conflicts=('foo')
provides=('foo')

#pkgname=foo; pkgver=2.0; unset provides # works
#pkgname=foo; pkgver=2.0.r0.g0; unset provides # works

# Changing bar to depends=('foo-git>=2.0') fix some of the following

#pkgname=foo-git; pkgver=2.0.r0.g0 # does not work (fixed)
pkgname=foo-git; pkgver=2.0.r0.g0; provides=("foo=${pkgver}") # works
#pkgname=foo-git; pkgver=2.0.r9391.4b4b5c5c; provides=("foo=${pkgver}") # works

#pkgname=foo-git; pkgver=2.0 # does not work (fixed)
#pkgname=foo-git; pkgver=2.0.r0.g0 # does not work (fixed). This is the most important one!

package() { :; }

> I should not need to explicitly name the version that is already in pkgver.
Yes, you should. It's not reasonable to assume versions for all provisions. Thinking solely about foo-git providing foo is narrow minded. Consider what happens when something like 'util-linux' subsumes a utility (e.g. eject) or when you start dealing with virtual providers (e.g. ssmtp and postfix provide 'smtp-forwarder').

> The version checks must be orthogonal or we'll get the impossible version dependencies we see in the forums from time to time.
This doesn't make sense. Could you provide examples of such forum posts?

I finally came to the same conclusion. foo-git could draw the version from pkgver only because foo and foo-git are likely to be versioned the same. Rewriting foo 2.0 as newfoo 0.1 results in a brand new set of versions from which pacman can't assume anything about versions.

Then the bug is in the documentation. This peculiarity needs to be explicit.

A provides without a version can only satisfy a non versioned dependency. If a versioned dependency is expected then a versioned provides is required. For example, if some package depends on cron, any provides=('cron') or provides=('cron=AnyVersion') can satisfy it. However if some package depends on cron>=2.0, a cron compatible package such as dcron with provides=('cron') shall not satisfy it even if the the dcron pkgver is >=2.0. dcron must explicitly add cron=2.0 to its provides array. Though not generally practical, the versioned dependency can also be modified to match the exact package name.

Where possible, vcs packages should include a simple non vcs version number in provides in case other packages need explicit versions.

> Then the bug is in the documentation. This peculiarity needs to be explicit.
The description of "provides" in PKGBUILD(5) states: "Versioned provisions are also possible, in the name=version format." This implies that versions aren't assumed. If you think the documentation could be clearer, please provide a patch against the git repo to the pacman-dev mailing list.