OGS Engine

That would be hilarious!
Well, initially I was thinking about "Evol" - a set of optional community improvements for the engine, but now I'm keen towards keeping the engine closer to vanilla GS (I even kept the Quake sources in C because of that)
One of the planned "Evol"'s features was the render dll support (so there will be one engine module and 2 (gl & software) + N render modules this way)
There's still a possibility that "Evol" will be supported, but I doubt that
The reason is that I have another project which uses the same codebase (let's call it "OGSNext" for now) but goes further and to put it simply, it's like a "custom version of Source engine", or, to be more correct, another path of GS engine evolution
It will be highly modular and provide a set of new APIs for both the engine and the game logic code (and a lot of other improvements), but it will remain closer to GS and its file formats
From the beginning OGSNext was planned like a "sleeper", so by default, it will pretty much look and feel almost the same as vanilla GS/OGS, but with a couple of changes/"swings of magical crowbar" (like hot-swapped modules and cvar modifications maybe) it will look like a modern-time game
I won't be talking about all the details here, but I'm planning to implement RTX support in OGSNext
On the other side, I'm looking at OGS as at a replacement for the original GS and its source code (because there is no hope that Valve will open-source the original GS and because it, at the same time, is already, at least partially, open-sourced (GS reuses a significant amount of Quake/Quake 2 sources))

Thanks!

You can build the engine yourself, it doesn't have any dependencies atm
Or you can wait for the next major release with SDL2 support and a lot of other improvements

I'm working on it in my free time and when I'm in a good mood. I'm also looking at how much people are interested in the project and that influence my willingness to support the project. So the more people interested in the project and actual contributors - the more performance from me

* Original GS engine researching
* Documentation writing
* Engine code writing
* Game (client and/or server) code writing

Engine logs/backtrace logs/dlls internal strings/engine behavior comparison/hlsdk code researching (some engine pieces were simply moved to game code space + it contains some headers with engine APIs (though, they're legacy and might not even be used in modern GS))/source sdk (Source went even further and moved even more stuff to game code so it can be used for reference purposes)/etc
You don't really need the reverse-engineered code, GS reuses a lot of id Tech 2 technology. HL:A is mostly a heavily modified WinQuake (NetQuake), final HL release has QW improvements on top of it + Q2 improvements after that + Source (id Tech 3) backports maybe. OGS is almost identical except that it lacks some of the key GS features that were already present in HL:A (when GS was closer to NetQuake rather than QW)

It looks like you haven't read engine's repo README file because it answers most of your questions
Of course it will run GS HL binaries, the engine specifically aimed to be an open-source reimplementation of the GS engine (without reverse-engineered code to allow people to create and redistribute their mods through Steam or ModDB (because Valve forbids to use their HLSDK with Xash3D or any other engine reimplementation/purpose)). Original VGUI1 will be reused in such case via an intermediate module. Most of the other mods (binaries) will be supported as well, but if you want to use the engine for your own mod, then you're allowed to use only reimplement SDK and game code and no HLSDK code. That also means no access to VGUI1 but it's legacy anyway, so there will be access to reimplemented VGUI2 instead for new client dlls (based on OGS engine internal SDK)