I've discovered a bug in SQL Server 2012 where certain queries can give different - and incorrect - results at certain degrees of parallelism.
Essentially with the reproduction script provided the query will give 8 rows (correct) at MAXDOP 1; 16 rows (duplicates of each row) at MAXDOP 4; and 16 rows (duplicates with two incorrect rows) at MAXDOP 8.
I've attached a setup script and reproduction script. The setup script creates a database called ParallelismBugDB, creates a set of tables, populates those tables with data, and loads statistics for those tables from our production environment (so that the optimizer will choose the offending plan). The reproduction script runs the query that displays these inconsistencies with MAXDOP 1, MAXDOP 4 and MAXDOP 8 (freeing the plan cache between each run).
It would appear that there are two bugs here: the first being the differences between the number of rows returned for MAXDOP 1 and MAXDOP 4 cases; the second (and more concerning) being the logically incorrect results returned in the MAXDOP 8 case.