Clearly getting SWIG and Windows to play together nicely is a bit of a big ask, but it may be possible to leverage GPGME's compiled libraries with something like CFFI's ABI calling method (yeah, I know, ABI is never ideal, but it's better than what Windows has now).
Testing this is already on my todo list, but it'd probably require a very static build so that it can be made to work on whatever type of Windows system people have. As distinct from the complete lack of them here (unsurprisingly).
Though a CFFI/ABI solution may be the only option, it would still be preferable to get SWIG working under Windows. The reasons for this are many, but not least of which would include not needing to duplicate effort to accommodate Windows, no functionality mismatch due to using the Windows version and not needing to implement every function manually since CFFI can't generate low level bindings the same way that SWIG does.
This has meant delving a little deeper into SWIG's documentation and one matter which needs confirmation relates to the compilers used to build GPGME, SWIG and Python on Windows systems. It is possible that for at least those three things and possibly for the rest of the GnuPG stack as well, they all need to be the same compiler and libraries. SWIG, however, includes a requirement that it must be built with the GNU utilities and nothing else. The GnuPG stack has no problems with that restriction if necessary and Python can be compiled with it too. It is, however, highly likely that Windows users are not installing Python by compiling it from source themselves, it is more likely that they're using the Windows installers available from the Python website and for fairly understandable reasons. Still, it could very well be that that precompiled version of Python is what cannot work with SWIG rather than Windows in general.
Unfortunately confirmation of this theory requires access to a Windows environment to develop and test in which is presently unavailable.
Whereas it is possible that a variation on a possible solution for another platform which could also be developed on a non-Windows platform could become an alternative option here. This, however, requires a little more investigation too which may be conducted during the course of other aspects of the bindings development.
Commit 8613727f1ee985c3cfa2c815523312914f033ffd adds considerable detail on both the issues affecting compiling and installing a Windows version of the bindings and what it would take to actually resolve it.
A subsequent discussion with @aheinecke led to raising the possibility of including a precompiled build of the bindings for whatever the latest stable CPython minor version is released from python.org and including that as an optional extra with GPG4Win.
If testing of this is successful then we can at least provide an “out of the box” solution for Windows users with whatever is current at the time and, of course, a replicatable build process for others to adapt to their own circumstances if necessary.
It will not, however, be feasible to provide multiple CPython version builds simultaneously, as can currently be built by default with installations on POSIX systems. On the other hand, it would mean we could maintain the standard answer regarding doing anything with GnuPG on Windows and cite Intevation and GPG4Win as the solution.
Though not directly related to our issues, this bug report on the MSYS2 site reported by their users encountering trouble with GPGME provides additional weight to irreconcilable differences between MSYS2 and GnuPG:
Specifically that the MSYS2 devs are explicitly not supporting 64-bit architecture.
So that's that. It also indicates that their project will dead end in early 2038, if not before.