Simple query returns wrong results in Sql 2012

Question

On my Windows 8 box running Sql 2012 11.0.3128, this query returns an IncludeCount of 0 and an ExcludeCount of 1.
On my Windows 7 box running Sql 2008 10.50.2550 this query returns an IncludeCount of 3 and an ExcludeCount of 1, which is correct.
In short, it runs properly on these versions of OS and Sql's:
Windows 2008 R2 + Sql 10.50.2550
Windows 2008 R2 + Sql 10.50.4000
Windows 2012 SP1 + Sql 11.0.3000
Windows 7 + Sql 11.0.2100
And gives incorrect results on these OS's and Sql's (so far, tested):
Windows 8 Enterprise + Sql 11.0.3128
Windows 2008 R2 + Sql 10.50.2550
I wondered if anyone else can reproduce this?  I can't figure out the magic combination of OS and SQL version this breaks on.
In all scenarios, the resulting @filters table is populated correctly, and the [Include] column is properly set to a 1 or a 0, so why aren't the other variables being properly set?
If I change the [ID] column to NONCLUSTERED, it works fine, too.  It doesn't matter if @filters is a TVP or a temp table or an actual table, same (incorrect) results in each case.
DECLARE @filters TABLE([ID] bigint PRIMARY KEY, [Include] bit)
DECLARE @excludecount int = 0
DECLARE @includecount int = 0
DECLARE @id bigint
INSERT INTO @filters ([ID])
VALUES (1), (3), (4), (-7)
UPDATE @filters SET
    @id = [ID],
    @includecount = @includecount + (CASE WHEN @id > 0 THEN 1 ELSE 0 END),
    @excludecount = @excludecount + (CASE WHEN @id < 0 THEN 1 ELSE 0 END),
    [Include] = CASE WHEN @id > 0 THEN 1 ELSE 0 END,
    [ID] = ABS(@id)
SELECT @includecount as IncludeCount, @excludecount as ExcludeCount
SELECT * FROM @filters

Answer 1

What part is undocumented?
http://technet.microsoft.com/en-us/library/ms177523.aspx
The above link states I can update variables inside an UPDATE statement ...
But it does not say what the correct result of what you are trying to would be. Variable assignment in UPDATE only makes sense if the UPDATE hits one row. If the UPDATE matches several rows, which value you the variable is set to is not defined.
It gets even more complicated when you have the variable on both sides of the expression. But I'd say that the only two values that makes as the final value of @includecount 0. An UPDATE statement, like other DML statements in SQL, is logically defined
as all-at-once. There are no intermediate results. Therefore the only possible values are the initial value of @includecount plus the value of the CASE statement, which always should returns 0, since @id is NULL when the UPDATE statement starts to execute.
I'm afraid that what you have is nonsense from a language perspective, and the result is undefined. Whenever you get different results from a query depending on whether you have certain indexes in place, you know that the query is indeterministic. There
are certainly part of SQL that are indeterministic, for instance ORDER BY on a non-unique columns. But in this particular case you have also wandered out into the land that is also undefined.
I'm not sure what you are trying to achieve, but I can only advice you to go back to the drawing board.
Erland Sommarskog, SQL Server MVP, [email protected]