Queued updating subscriptions
I undid again, which reverted them all back to 'for replication', then generated but did not run a publication script (with SQL Server Management Studio's GUI), and executed each command one at a time, checking the state of the "not for replication" setting along the way.
When published data is changed at either the Publisher or the Subscriber, the row receives a new globally unique identifier (GUID) to indicate that a new row version exists.
This is because set updates made at the Subscriber are propagated by replication as individual UPDATE statements for each row affected.
When data is updated at a Subscriber, it is first propagated to the Publisher and then propagated to other Subscribers.
Conflicts are detected and resolved according to a conflict resolution policy that is set when creating the publication.
When the conflict resolution policy is set to Subscriber Wins, updates to primary keys should be made with caution.
I configured Queued updatable subscriptions in transactional replication.