I ran into this when building from gpgme-1.9.0.tar.bz2 as part of building LibreOffice, on macOS (on a case-insensitive file system) against trunk LLVM libc++ (that includes a <version> header file that gets included from other libc++ headers like <string>): "When compiling e.g. [...]/lang/cpp/src/parser/exception.cpp, libtool adds -I../../.. (presumably to find files like [...]/config.h), and including e.g. <string> internally includes <version> now, and [...]/VERSION happens to win. [...] (An alternative approach might have been to use -iquote../../.. instead of -I../../.., but that's probably hard to shoehorn into the libtool-generated compiler invocation.)", see https://cgit.freedesktop.org/libreoffice/core/commit/?id=689b6a6ceb88b2c074b77c1030bc2396a1816eea "external/gpgmepp: Clash between VERSION and trunk libc++ <version>". (And what I do for LibreOffice for now is to remove the VERSION file from the unpacked tarball, and nothing appears to be missing it.)

I checked that recent trunk gpgme make dist still generates the VERSION file into the tarbal's root directory; what I didn't check is that building from the tarball would still run into the issue where a file is compiled with some -I switch pointing at the tarball's root directory, where it would erroneously pick up the VERSION file for an #include <version> in one of the libc++ headers.