I agree with Clare - perhaps initialising the second subscription removed all trace of the first.

As for the Identity and BranchID - that is fine PROVIDED that you declare the combination of these 2 columns as the primary key. This is what transactional replication will use to determine what to update/insert/delete. I am not sure that it makes sense to have the identity property on the subscriber - I have never tried it but it seems to me that you normally expect one and only one record with a value for this column. You would end up with 2 or more - not sure that SQL Server will be all that happy with this. You might need to test this (especially check what reseeding does for this table on the subscriber).

As for merge replication, you still need a primary key. Merge also needs a rowguid column. Whilst this would be unique, it may or may not be the primary key. That is up to you. The same issue with identity would exist. Merge could work.

I have implemented solutions with both merge and transactional replication in similar environments in the past and they work quite well. The only difference between those and yours is that instead of identity, we generated the key values (using something similar to the branchid plus a sequence number).