Thanks Spatzi for that very detailed answer.
Race-specific tech trees for fantasy mods is a topic that pops up on a regular basis. It's unfortunate, but the game just isn't really structured to support that as a retrofit to the existing tree. Too much of the existing game is mixed together in a way that really isn't supportive of that sort of thing.
But all hope is not lost. While a TechClass setup would make this sort of thing trivial, the way it's structured is actually not bad for this
if you specifically design a tree around that mechanism. The key is to not have multiple distinct trees, but to instead have a single tree with designed variation points that converge back into the main tree after only a brief deviation. As a practical example, think of Age of Empires; each race had very similar "tech trees", just with holes in different places.
So you could easily replace a single tech with race-specific alternatives, which had slightly differing prerequisites. The only headache is merging back together; this only works for techs whose following techs ONLY require them, because you're going to abuse the OR mechanism to do this.
For instance, consider a tree with techs A, B, and C, all at the same tier, right next to each other. You want these to be somewhat exclusive, where each civ has access to two of them but not the third, which means you need to work around the hole this creates. So, you create two more techs, D, and E, where D follows from A/B/C, and E follows from D. Like so:
You can make the stretch after D as big as you want, where it might go for an entire era before rejoining the "main" tree. The only limitation is that E must depend ONLY on D. If you want to create a whole block of techs that are race-specific then you can do that, but the tech that rejoins the main tree (E) MUST only depend on a single tech.
The catch is that you're not making a single tech D, what you do is create D1, D2, and D3 to replace D. D1 requires A and B but not C, D2 requires A and C but not B, D3 requires B and C but not A.
E then requires (D1, D2, OR D3), meaning every races' techs connect back together at that point. Since techs like E use an OR, they can't require any other technologies, which is what makes this incompatible with the existing tree. But again, designed tree, less problems.
So far so good. Now, we're still left with the problem of having the player have access to all three D techs. So we create race-specific techs 1, 2, and 3, where each race begins the game with one of those three but can never gain the other two.
To make things go even smoother, we should also create techs X, Y, and Z, where X is given to the 1 group and the 2 group, Y is given to the 1s and 3s, and Z to 2 and 3. (We need these for the "not 1" setup, so that we can use an effective OR merged with other ANDs.) So the "Human" civ has 1, X, and Y, while the "Zerg" has 2, X, and Z, etc. These techs don't even need to be given effects if you don't want any core differences between the races, but maybe you want the worker units for each race to have different stats or something.
With those, we can now change things a bit: D1 requires A, B, and 1, D2 requires A, C, and 2, D3 requires B, C, and 3. Since D1 doesn't require C, we can either make C require Z (which means anyone with 1 won't get it at all), or have it act as a dead-end tech for that civ.
All of this works in XML, with no need for any Lua hacks. The only question is the UI, which'd require a small amount of modification to only show the techs your civ has access to.
-------
The fact is though, it's mostly unnecessary to split techs like this. There's no rule that states that a Unique Unit/Building has to be at the same tech as the unit it replaces. So you could easily put the European Swordsman at one tech, the Asian Swordsman at another, and the American Swordsman at a third one. It's more suited towards the total-conversion concept, where entire eras will be distinct.
But again, there'd be problems with the barbarian faction, and city-states, unless you made sure they had limited access to the rewards for these techs. The existing UnitOverrides and BuildingOverrides tables actually work well for this.