I'm wondering if what's happening here is that the dev2 database was rebuilt which reset the sequence values on the table. So in memory in rice-remote-test-client we had services which had been successfully published originally sitting in our list of local services and they had a hard-coded id associated with them (because they had previously been published). Then when we try to republish them it sends an id which is already there in the database.
One thing we can do combat such situations would be to clear out the id of the ServiceInfo before we publish it.
Either way, this is the kind of thing which would never be a problem in a production environment, so I'm going to push it to 2.1 so it can be dealt with there.