"Interfaces" could mean several things.
(a) process (pipes, parsing) based interface to existing external tools. (b) interface to existing tool *libraries* (c) direct "interface" to the repository data, meaning a reimplementation.
As mentioned I've already done part of (a) for git (parsing git-log output). This is also the approach stgit (written in Python) is using.
There has been a Google SoC project proposition about creating working library versions of the git tools. From what I hear this project is on it's way now. From reading the git mailing list, it will probably not become reentrant, though. This may or may not be a problem for you (for writing web applications using multithreading, chances are high that it is a problem; forking or starting separate processes being a possible workaround, which probably won't work well on Windows).
I don't know why GIT is slow on cygwin; one reason could be process startup/forking overhead (but some tools, like git-log, don't fork/exec at all, so they should be as fast as on linux--are they?). Another reason could be stuff that might not be directly mapped by cygwin (handling of file descriptors? mmap? no idea). If you want a fast windows version, (a) or possibly also (b) would not be solutions (without reworking the git code). Reimplementation in (mostly-)Scheme could avoid process startup and mmap usage. I've never programmed for windows (if necessary I could try to get into it enough for this stuff).
I'm relatively confident to be able to write an implementation for reading and writing single-object files, reading and writing pack files, and the infrastructure for git-log, -add, -rm, -commit and trivial merge functionality in about three weeks if I'm getting funding for it (800 USD would be enough). The more higher level parts like e.g. merging of files and remote interaction would not be included in this work (I could probably take care of those too with more funding; but I don't think I will ever need those in my own future work). However, I would take care that performance is good (this could include LRU caching, if necessary, and taking into account the hints about the problems on Windows), and that it's reentrant for Gambit threads and that other Gambit threads aren't being blocked for inordinate amounts of time. So I think what I can offer is in-process and properly multi-threaded lowlevel git repositoriy handling which should work equally well on Windows; the stuff on top of it may be large enough (or then maybe not) to be afraid wanting to reimplement it; maybe others would do it with less funding, or maybe for those tasks the normal git utilities or the forthcoming git library are working well enough. (BTW note that I would reuse the C xdiff code used for handling deltas in pack files, which is GPL, so the license of the whole thing would probably have to be GPL. Unless I'm also being funded for reimplementing xdiff.)
A possible alternative solution, if the performance issues are only process forking/startup overhead, may be to take the Git tools code and basically call their main functions, but leave them up running for reuse as long as possible (they'll exit on error, for example, might leak memory, require reinitialization code or other evil hackery). I hear someone tried this already for calling from Perl. I'd probably link them with Gambit to have Scheme on both sides of the pipes (this should make development and communication somewhat easier). I'm not so sure whether I'd want to invest time into this kind of solution; it might be better to wait for the Git library.
Regarding generic interfaces, I don't know. I only know CVS, Git and a bit of Arch, SVN and Darcs. Developing generic interfaces would probably be a task to be done by someone writing an application, after individual interfaces to multiple systems are already there. Possible starting points for digging out knowledge could be the git-svn, git-arch, git-cvs tools, and maybe the versioning system access code in Eclipse. (Actually I'm an Emacs user, but I'm not aware of a multi-versioning repository interface in Emacs. Is there any?)
Christian.