hehe, what you describe is multi-horizon-flooding.

Let's brainstorm: I don't think horizon travelling _must_ be unhealthy, it could be. See it like a sheep: once every grass stem on the meadow is eaten, it does walk to the next meadow nearby. A sheep does not constantly hop and run around like a crazy sheep and eat every stem it could get on the whole wide world. *grin-imaginating-a-crazy-sheep*

Modern gnutella client do allready generate automatic researchs (for resuming files e.g.), together with a highly recommended query cache this is nothing unhealthy. Going into far future (assuming query caches are present in every servant/superpeer - important!):

Horizon traveller could use hostcaches to find a brand new horizon (best thing) - or just creep along horizons by quering neighbour IPs with an TTL=1 IP time by time (not that good idea maybe, I guess horizon border hops are better, but how to achieve that?)... until they find new "rich medows". If automatic search queries are within limits, there is no significant higher traffic IMHO.
As a counterthesis: By dynamic restructuring of horizons with more specialized content, there will be a more efficient traffic, because searchqueries does only reach interested hosts not various hosts (seeing gnutella network at whole = multiple horizons).
So far my theory, maybe I'm wrong, that's what I ment with "sounds interesting". Propably the idea of 'specialized gnutella horizons' (described on top of this thread) looks like a more promising approach for horizon travelling. It does include a automatic horizon travelling, because connected hosts drop time by time and must be refreshed. However a seldom horizon travelling or parallel travelling on purpose must not be unhealthy: gimme music in one specialized horizon and this outer space cookie recipes in another specialized horizon.

Greets, Moak