Because when you take the code, then make it incompatible with the original product, that is a fork. Forking is something frowned upon because it splits the fanbase and potential developers in two, ending up getting nothing done for the original product, and the fork going nowhere.
Forking is advantageous because it generally only occurs when 2 people have different visions of how a project should proceed. This leads to two different projects that have diverging goals and consequently are quite different to each other. You don't split the fanbase because the projects end up doing two different things. Same idea with the devs. The devs aren't paid so they generally code things that they're interested in. This means that a fork won't necessarily draw devs away from the original project because the fork will be doing something different. Not to mention that code can be shared between each project.
Why would it go nowhere? Because the fans of the original product get bored and leave, while the fork gets none of the users of the old product, thereby leaving it in a state of useless development for nobody.
Trem hasn't had a release in over 3 years. I don't think we have to worry about people getting bored and leaving. Even if the fork doesn't get many of the old projects fans (it's quite likely because lets face it, a lot of people run Trem because of it's modest system requirements) it will attract new fans because of the different direction it's heading in.
Forks are sometimes beneficial(take a look at XFree86/Xorg), but in this case it's of no use to anyone to take the code then break compatibility, when you could be sending patches in to the original product, furthering it to 1.2 status. I believe TremFusion will go the way of Cedega, having some nice features but eventually being phased out by the original product(Wine).
Cedega is in a completely different boat. Unlike Cedega and Wine both Tremulous and Tremfusion use the GPL. This allows them to share patches which Cedega and Wine can no longer (or aren't willing to) do.
The XreaL renderer is nice but there has yet to be a discovered way to port it in its current state to ioQ3 without breaking compatibility with 1.1 servers. The XreaL renderer depends on a new BSP version, which means all maps would have to be recompiled, not to mention converted to Doom3 format first. Think this is easy? Think again. I've gone through this grueling process. It is not fun or worthwhile.
Was it easy to make the maps in the first place? People have already expressed interest in creating maps for a Tremulous which uses an XReal engine.
Poll