Thanks kryo. Pre-edit, my response frlt like it came off snarky after I hit submit

 In my experience with modding galcivII /II, just about any function/tag can be copied from one xml into another xml since the individual bits seem to work a lot like unix style command piping where  have it work fine after adding stuff to the xsl's if needed(f/ex I've used upr/shipcomponents/planetaryimprovements/etc stuff in colonizationevents, ideology, plametdefs,   buildings,  with success).  GalcivII was more likely to crash while galcivIII has a better validation.  modders only have one side of the coin (the xml/xsl with the compiled binaries black boxes), sometimes we throw things at the fan to see what passes through .  When I did my galcivII modding, there were some very very old threads that turned out to be more useful than people likely expected at the time, maybe this one will be too... if nothing else it's a good "here's a bunch of stuff that won;'t work, nobody has found something better"

All things being equal, the fact that <RootNode>true</RootNode><ResearchCost>0</ResearchCost> makes a seemingly untradable tech you can assign at the start of the game & that things can be gated with multiple tech prereequ's (I think) or either/or prerequ's(some of the extreme planets are a good example) gives it a pseudo option for modders in the future.  Having the details on galcivIII beta4 patch1's results documented above could be beneficial for folks later when more options/different validation might be in place after a few dlc/expansions & the rootnode makes for what looks to be a good partial option till then if nobody figures out another option:).

While It's possible that just clicking ignore instead of skip/quit might not worked at all have worked fine, I have family visiting the next couple days & won't get to test it any time soon. .  The engine for processing the xml files is remarkably robust & flexible (even more than galcivII's where starbases & a couple other things used unique xml tags)... since I don;t think that was a upr  in gcII, it seems reasonable that it would follow suit with the increased flexability & openness. 

so the answer is to make up a unique generic name? 

i was going to say there should be several techs already that cant be traded the krynn's 'the way or the path' techs w/e they are called the yor's spark of life techs

While I agree, & think I know how to make that work (details below), thanks to what thecw & androshalforc added while I was out having korean bbq with visiting family, changing that would require going into the various xml files that reference those techs & setting them all to function like frozen world in planettraitdefs.xml where you can have

<ColonizationPrerequ>
<Techs>
<Option>ExtremeWorldColonization</Option>
<Option>PropagationTech</Option>
</Techs>
</ColonizationPrerequ>

or anything in the tech tree that has a foldout as one of the prerequ's i.e.:

<Prerequ>
<Techs>
<Option>IndustrialSpecialization1</Option>
<Option>IndustrialSpecialization2</Option>
<Option>IndustrialSpecialization3</Option>
</Techs>
</prerequ>

assuming <prerequ> can  also support <option> under whatever recognizes those things that shouldn't be tradable, but since almost everything gated is gated by the tech tree in some way, or exists in a file where something is gated by a tech, that last option will likely work almost everywhere

regarding thecw's comment, giving it a cost & prerequ  (as noted) appears to tkip the need to actually research it  but shows it on the tech tree, , removing the cost & prerequ should prompte the tree to a forestm but the new tree doesn't appear to show anyplace I could see (and makes a nice hidden gateway as a result:).  in my testing, the yortesttech was only in the yor tree... as noted by thecw & androshalforc to varying degrees, giving everyone else $racenaametesttech rather than just testtech for the genericname would work great for purposes of future mods regardless of weather or not a fluff item is shown on the tech trees.  ot looks like I got one to work but it was working for a different reason than suspected & I didn't go digging because my idea didn't need it to show up

Since it seems like the solution is looking like it will be "give every race a tech with unique GenericNames", it might be something that should be included with final release for purposes of mod interoperability rather than make anyone who might have some reason to make something behave differently for different races go making custom tech trees for each affected race.

I didn't include the relevant bits in my first post by oversight, bur I was originally trying to combine this:

<UPResolution>
<InternalName>TechnologyNonInterferenceAct</InternalName>
<DisplayName>TechnologyNonInterferenceAct_Name</DisplayName>
<Description>TechnologyNonInterferenceAct_Dec</Description>
<Question>TechnologyNonInterferenceAct_Question</Question>
<VoteType>
<VoteType>YesNo</VoteType>
</VoteType>
<PersonalityTraitModifier>
<PersonalityTrait>Scientific</PersonalityTrait>
<VoteInfluence>-10</VoteInfluence>
</PersonalityTraitModifier>
<PersonalityTraitModifier>
<PersonalityTrait>Spiritual</PersonalityTrait>
<VoteInfluence>10</VoteInfluence>
</PersonalityTraitModifier>
<Behavior>BlockTechTrading</Behavior>
<Modifier>
<EffectType>CreditsPerTurn</EffectType>
<Scope>UPResolutionGalaxy</Scope>
<Target>
<TargetType>Faction</TargetType>
</Target>
<BonusType>Multiplier</BonusType>
<Value>-0.01</Value>
</Modifier>
</UPResolution>

with a modified bolded bit from this:

<UPResolution>
<InternalName>UnitedPlanetsResearchFoundation</InternalName>
<DisplayName>UnitedPlanetsResearchFoundation_Name</DisplayName>
<Description>UnitedPlanetsResearchFoundation_Dec</Description>
<Question>UnitedPlanetsResearchFoundation_Question</Question>
<VoteType>
<VoteType>YesNo</VoteType>
</VoteType>
<PersonalityTraitModifier>
<PersonalityTrait>Scientific</PersonalityTrait>
<VoteInfluence>10</VoteInfluence>
</PersonalityTraitModifier>
<PersonalityTraitModifier>
<PersonalityTrait>Xenophobic</PersonalityTrait>
<VoteInfluence>-10</VoteInfluence>
</PersonalityTraitModifier>
<Behavior>ResearchDiscount</Behavior>
<SpecialValue>
<Special>ResearchTag</Special>
<ValueParam>0.25</ValueParam>
<StringParam>NonMilitary</StringParam>
</SpecialValue>
<Modifier>
<EffectType>CreditsPerTurn</EffectType>
<Scope>UPResolutionGalaxy</Scope>
<Target>
<TargetType>Faction</TargetType>
</Target>
<BonusType>Multiplier</BonusType>
<Value>-0.05</Value>
</Modifier>
</UPResolution>

Since the stringParam can be almost anything (I experimented with in in 0.61) so long as you go through the tech trees & add new    <Tags>Not-NonMilitary</Tags> to techs (worst case it just applies to no techs iirc)  it seems like combining BlockTechTrading with a <special>ResearchTag</Special><StringParam>NewTag</StringParam>might be a far more elegant solution since it would only require modding the one tech,  not break any mods that rely on that gateway tech simply existing as a gateway,  while also also allowing BlockTechBrokering & any other Block options I've overlooked from other locations.  Unfortunately, I couldn't find a way that it liked existing in the tech tree rather than the UPResolutions.xml.  a useful workaround for the future might be if we could set a UPResoltion to be in effect at turn0 with things like:

Not repealable:

<VoteType>
<VoteType>AlwaysTrue</VoteType>
</VoteType>

Repealable:

<VoteType>
<VoteType>DefaultTrue</VoteType>
</VoteType>

It would still require modding one or more techs, but not all of the things that use them as prerequ's where mod interoperability could become a more likely issue. I originally started looking into this out of a desire to figure out if pulling together ideas for a later mod was something even possible  (massively expanding the non-extreme worlds in PlanetTraitDefs.xml) like desert, breadbasjet, shielded, etc to have race specific     <ExtremeTypeModifiers>top where different races get different benefits from different new additions.  Since the ability to seed them into  PlanetDefs.xml  (or whatever defines just habitable worlds, I'm pretty sure I've seen it before) is only a "would be nice" part of the idea, I stopped testoing at finding an untradable tech