I know what you mean about the data forking as it relates to the hostname and IP address, an example is where a set of gmonds are running and only a pair of them have tcp port 8649 listening, and one of them has a custom hosts file or certain knowledge of ip to hostname mapping that differs from the other gmond server. In a fail over situation the other gmonds data will be used and certain ghost hostnames will show up as down in the gmetad output. I would be ok with having a migration tool available that first could be used to identify hostname/ip descrepancies in a set of rrds, and then a followup command could be run to do any needed migration. A script that can use those tools to clean things up in a smart way on a daily basis could follow. But it seems to me the way to avoid this problem in the first place is to for example set up nameserver entries properly in the first place so that they are consistent, you can for example set up a tinydns internal nameserver and make sure all your gmond machines are using it.
Lester
