A MERGE statement can fail, and incorrectly report a unique key violation when:
* The target table uses a unique filtered index; and
* No key column of the filtered index is updated; and
* A column from the filtering condition is updated; and
* Transient key violations are possible
The optimizer incorrectly chooses a narrow update plan where a wide plan with split/sort/collapse is required to avoid transient nonclustered index key violations.
Forcing a wide update plan with TF 8790 (or by adding all columns referenced in the index filter predicates to the index *keys*) avoids this problem.
There is a reproduction script in the details section below, and a fuller discussion at http://sqlblog.com/blogs/paul_white/archive/2012/12/10/merge-bug-with-filtered-indexes.aspx