Adding/removing wormholes in AIWC was a royal pain due to the very specific way they were handled (including the fact that originally they weren't even serialized to disk, the mapgen was just rerun for that stuff whenever you loaded).
In AIW2 it's much easier to add/remove wormholes.
For removal I'd use planet.
GetWormholeTo(otherPlanet) , wormhole.
Die() , planet.
RemoveLinkTo(otherPlanet) .
For adding I'd use planet.
AddLinkTo(otherPlanet), and then 2 sets of wormhole = GameEntity.
CreateNew() (search external for SpecialEntityType.Wormhole to see how) followed by wormhole.
LinkedPlanetIndex = planet.PlanetIndex .
You could probably even add planets, though not remove them (to "remove" you'd need to suppress them somehow, to avoid messing up index positions). Getting everything to play nicely with the modified map is a different kettle of fish, but should be doable.
First, as you said, breaking the graph is out. That would cause no end of problems. That said, you could add a compensating connection before removing the existing one, and that would let you do this on Snake. It would probably result in a map that gets progressively less snake-like, however. On that note, it would be kind of fun to have a map type that changes from, say, Concentric to Wheel over the course of the game, by moving stuff around and relinking. Or a maze type where the "labyrinth" gradually reconfigures itself. On the other hand, that sounds like a defensive nightmare. On the third hand, many AIWC players seem to enjoy nightmare difficulty
Second, pathfinding needs to be notified:
1) If removing a wormhole, all units with a wormhole order to enter the planet on either side (or who are _on_ either planet and have a wormhole order going anywhere) would need to have their paths rerolled. Same as AIWC, not terrible, but needs to be done.
2) Whether adding or removing, RecomputePlanetDistances() needs to be called on the galaxy object. This rebuilds the cached lookup used by planet.GetHopsTo(otherPlanet), which is used for pathfinding costs.
Both of these would need to be done at a stable time between long-term-planning cycles (so the graph isn't changing while the AI thinks, etc), which basically means when I handle GameCommandType.HandleEndOfLongRangePlanningCycle (in core). So perhaps I should provide a HandleEndOfLongRangePlanningCycle() hook for conducts and factions to define in external, and it could be done there.
And theoretically that's it. In practice I'm sure there would be some race conditions with vis code and possibly some other parts of the sim that need to be notified, etc.