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(7) 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 SLONIK SUBSCRIBE SET(7) operation with the new subscription information for the node; Slony-I will change the configuration. No need to ask for SLONIK UNSUBSCRIBE SET(7); no need for it to start copying data from scratch; the SLONIK SUBSCRIBE SET(7) request will reshape the subscription "on the fly" and allow data to remain consistent between nodes.
After performing the configuration change, you should, as Section 2, run the Section 5.1 scripts in order to validate that the cluster state remains in good order after this change.
The altperl toolset includes a regenerate-listens script that is up to the task of creating the new SLONIK STORE LISTEN(7) commands; it isn't, however, smart enough to know what listener paths should be dropped.