Deferred Updates happed even if the value does not change in SQL Server 2012

I am not sure if this was an intentional compatibility break for SQL Server 2012, but I have not been able to find any docs on it, so I am going to post it here to see.

We upgraded our SQL Server that publishes reference data to other servers.  The upgrade moved us from SQL Server 2008 R2 to SQL Server 2012.

After the upgrade we noticed that some of our replications would break because tables that were designed to never delete rows were trying to replicate deletes.

After a lot of research I found that my SSIS package that populates the source table every night was starting the chain of events that lead to the deletes.  This SSIS package fills a stage table, then does a MERGE to the "live" data.  (The idea is that any changes to data will then be replicated to the subscribing databases.  This all worked perfectly with SQL Server 2008 R2.)

The SSIS Package is very careful to never delete any rows.  Any NOT MATCHED on Source rows have an IsActive column set to false (not a DELETE).

However, after upgrading to SQL Server 2012, this merge statement would cause  every row in the table to try to publish a delete and an insert statement to the subscribers.

In an attempt to get to the point of this issue I need to define a scenario that can cause a Deferred Update:

If a MERGE statement has the clustered key in an UPDATE statement (in the MATCHED clause) then every row affected will post as a Deferred Update (Causing a Delete and an Insert to be published to subscribers).

However, new in SQL Server 2012, is the fact that even if the value of the clustered keyDOES NOT CHANGE it will still replicate as a Deferred Update.  Infact, even ifnothing in the row has changed at all, the row will still replicate a delete and an insert.

I tested this with traces an found it to be true and totally reproduceable every time.

So, I have 3 questions:

1. Has anyone else seen this?  (Can it be reproed by more than just me?)
2. Is it a Bug?
3. Is there a way around it (besides using a compatibility mode)? 
   (NOTE: Trace Flag 8207 will only work if you are updating a single row, my merge statement affects the whole table.)
   

For now we removed the Clustered Key (Primary Key) from the update part of the merge statement.  (It never, ever, changes, so we did not need it there anyway.)  But I would still like to know what is going on here.