PK as ROWGUIDCOL or use a separate rowguid column?
Basically, they say that the application should never bring into its domain something that is used by replication only (it's only "DBA stuff" for them).


I agree completely. But... the primary key isn't only used for replication (presumably the application uses it in some way). The argument makes no sense in this context.

In any event, as far as I'm aware, there are only 2 ways for this "DBA stuff" to cross the domain boundary:


If the application is using queries that reference the ROWGUIDCOL column like this:

DECLARE @a table (id uniqueidentifier ROWGUIDCOL);

SELECT ROWGUIDCOL FROM @a;


I'm assuming none of your columns have this property yet, so the application wouldn't be doing this. (By the way, ROWGUIDCOL is a completely separate concept from replication. It just so happens that merge replication uses it.)
The primary key column would no longer be updatable. If the application is doing this and changes aren't going to be made to use another algorithm, there's no choice but to add a new column to the table, and therefore no discussion is necessary.


Other than those behaviours, the ROWGUIDCOL property is completely transparent. You can add it, and the application would never know. Any type of data replication scenario should be as transparent as possible to applications.