From the context it sounds like you are referring to SQL Remote, correct?

Yes, when adding a column with a default clause using the alter table statement "All rows in the column are populated with this [default] value." The alter table statement doc provides additional details of behaviours and side affects around altering tables such as affects of other connections to table, etc. I'm not familiar with details of how SQL Remote processes requests, so I cannot comment further on your locking question.

It is up to you to set the partition using the global_database_id option. The section on assigning unique identification numbers to each database provides some ideas on managing the database IDs.

As Bill has explained, the DEFAULT VALUE will be set during the ALTER TABLE - which means that any Remote will fill the rows it contains with values from its own GlobalDbId range. In case several remotes (or the consolidated) will contain the same rows (which would be very typical), then different remotes would set different default values to the same row. And that would not be resolved by replication. In my book, that's a no-go.

In such cases (adding NOT NULL columns to non-empty tables) we have used a different approach that will only set the default value for each row at only one site - assuring that data remains consistent.

1. Use Passthrough mode (PM) to alter the table with a NULLable column. Stop PM.

2. Update the row in the consolidated with the according default value (i.e. by selecting get_identity() or the like), something like
   Update ABC set unique_cnt = ... order by MyPk;
   As this is done outside PM, the update will be replicated.

3. Use PM (only) to issue an update that only affects the rows in the remotes that have not already been updated in the previous steps (usually rows that have been inserted in the rows and are not yet replicated to the consolidated): Update ABC set unique_cnt = ... where unique_cnt is null order by MyPk;

4. Stop PM;
5. Use PM to change the column to have its DEFAULT VALUE and set it to NOT NULL. Stop PM.

I guess it's best practise to let SQL Remote run at the consolidated after each step (in send-only mode) in order to build separate message files for each step.

CAVEAT: (I'm not sure whether you could include the DEFAULT clause in step 1 without filling the new columns. If so, then in step 2 and 3 you could simply use UPDATE ... set unique_cnt = DEFAULT, methinks.)

As always, I would recommend to verrrrry thoroughly test your SQL Remote schema modifications...