If you rearrange the nodes so that they serve different purposes, this will likely lead to the subscribers changing a bit.
This will require doing several things:
If you want a node that is a subscriber to become the origin for a particular replication set, you will have to issue a suitable slonik MOVE SET operation.
You may subsequently, or instead, wish to modify the subscriptions of other nodes. You might want to modify a node to get its data from a different provider, or to change it to turn forwarding on or off. This can be accomplished by issuing the slonik SUBSCRIBE SET operation with the new subscription information for the node; Slony-I will change the configuration. No need to ask for UNSUBSCRIBE SET; no need for it to start copying data from scratch; the SUBSCRIBE SET request will reshape the subscription "on the fly" and allow data to remain consistent between nodes.
If the directions of data flows have changed, it is doubtless appropriate to issue a set of DROP LISTEN operations to drop out obsolete paths between nodes and STORE LISTEN to add the new ones. Up until version 1.1, this was not changed automatically; as of 1.1, MOVE SET and SUBSCRIBE SET change the paths as a side-effect. See Section 9 for more information about this. In version 1.1 and later, generation of sl_listen entries is entirely automated, so that they are regenerated when changes are made to sl_path or sl_path, thereby making it unnecessary to even think about STORE LISTEN.
The altperl toolset includes a regenerate-listens script that is up to the task of creating the new STORE LISTEN commands; it isn't, however, smart enough to know what listener paths should be dropped.