Sql-server – PK as ROWGUIDCOL or use a separate rowguid column

Intriguing question... as long as you have an actual scenario to apply it to it wouldn't be too difficult to figure out. Perform your BCP process, run sp_addtabletocontents and then before the subscriber syncs verify the existence of the records in the MSmerge_current_partition_mappings and MSmerge_past_partition_mappings tables.

According to this technet article that is where the partitioning data for each row that has been changed is stored post change/pre sync. Look into the article for deeper information and the manner in which the table structures are organized within the process. The link provided is for SQL 2008 but if the table structure is the same its a safe bet that the pre-compute logic is close enough to answer your question.

I am not an expert on precomputed partitions but it seems to me that it would have to take advantage of the precompute process (if enabled) otherwise it wouldn't sync these records at all.

The problem with IsDeleted is its low cadinality: 0 or 1. Which makes it unindexable and since all your queries will add IsDeleted = 0 to the WHERE (or JOIN) conditions this apparent trivial change complicates a lot of things. You covering indexes will all of the sudden require lookups into the base table to decide if the row qualifies or not. There are measures that can improve behavior, but they have to be properly considered and consistently deployed (note that some of these mitigation are mutually exclusive, evaluate them separately):

• add IsDeleted as the leftmost key in the clustered index. This effectively 'splits' the clustered table into two regions ('deleted' and 'active'). It also forces de-facto the IsDeleted column in every non-clustered index, thus avoiding the need to lookup the value.
• add IsDeleted as a leftmost key in every non-clustered index. May sound extreme, but can be quite effective, provided that all queries specify IsDeleted in the WHERE.
• add IsDeleted as an included column to every non-clustered index. Unlike the options above this does not change seek/range/lookup semantics of the exiting indexes, but makes the IsDeleted check filtering available in every access path. Can be quite effective specially if IsDeleted = 1 occurs seldom.
• make the non-clustered indexes filtered by IsDeleted = 0. May be effective on large tables, but is a bit dangerous as the filtered indexes become unusable for queries interested in the deleted rows.

A separate table for history makes a much more cleaner cut from the engine point of view: is a different table, no messy/risky plan choices to cope with. But it is much more impact on the application. If looking up the history of a row is the exception, the application changes are reasonable easy then I would consider this option first, as it has the least risk of (severe) performance regression.

I would strongly advise against mixed solutions (eg. tags and tags_history table and a view that unions them), such solutions have all the disadvantages mentioned above without any advantage. In general, anything that claims 'minimal impact' or 'transparent change' is snake oil. This (adding application layer row versioning/row history) is, by definition, a high impact change which will ripple big time in the application.