First step of solving the prerequirement loop problem
The prereq works fine until some spells can prereq each other.
For example, take 3 Water Spells, with two of them requiring 2 other Water Spells. If you add only the basic one and one of the other two, the latter will be shown red, because its requirement is not fulfilled. If we add the third, suddenly all three spells are black, because each of the two advanced spells has its two water spells prerequirement fulfilled. However, this is agains the GURPS rules.
This happens because the GCS doesn't acknowledge time of learning. Because I think adding this would be too much trouble, I tried something else, basically a loop detection by depth first search. I added marker lists to spells, one for each type of spell requirement: name, any, college and college count. The example described above can be applied to all these cases, although with names one would have to use at least "contains" instead of "is". In fact I excluded this case from the changes for GUI reasons (if only the prereq of a prereq is not fulfilled, the prereq will be shown red, but the spell of the prereq black, which seems intended). Now when a spell prereq is being checked if satisfied, it itself checks the satisfication of its prereq spells. Only satisfied spells will be taken into consideration to see if this spell is satisfied and loops will not occur.

What's the improvement: Satisfaction by use of loops (as described in the example) will no longer occur and spells who fell under this will occur red from now on. This loop situation is not common, but can happen from time to time. This should also work with "equal" and "less than" and "doesn't have", if you see spells not meeting their requirements as basically not being there. Except for the "whose name is", as I wrote earlier. So e.g. if I have three spells, the second (order is not important here or above) requires the third not to be here (never seen that) and the third requires two any spells. Then... Okay, wait, that's a loophole. Good, another thing for...
What's the downside: This is basically a draft. These last hours I worked on the code I saw this concept can be extended to all dependencies, although I never noticed it outside of spells; furthermore I don't know how to clever implement the different marker lists except by just listing them all up. Oh wait, a map to lists would probably do. Next thing is, I don't know what would happen with deeply nested prereqs, as the spell it comes from is marked all the time. This could cause problems, but I can currently not think of any examples. And last, I haven't tested the code, sorry!