For SQL 2000 (and the question explicitly includes "before SQL 2005") there is no way of specifying ignore_dup_key for a primary key. Any attempt to specify "with ignore_dup_key" in an alter table or create table statement gives the error "ignore_dup_key is not a recognized CREATE TABLE option" (or substitute ALTER for CREATE in that error message); creating a unique index with the option on the primary key columns and then adding the primary key constraint simply results in two indexes (and the one supporting the primary key doesn't have the option) unless the unique index has the name (whether default or non-default) used to attempt to create the constraint in which case the constraint is not created (error message says the named index already exists). So for SQL 2000 at least this part of the answer is wrong. And since this means that there can be no damage to the properties of the primary key the claim that the option leads to ANSI non-conformance on that ground also fails for SQL 2000.

The nondeterminacy caused by the indeterminacy of order of insertion of multiple rows in a single insert statement exists already without the ignore_dup_key, because (for example) identity columns will contain values which depend on the order. Select top n (without an order by clause) provides another example of nondeterminacy. It is therefor misleading to say that SQL Server's nondeterminacy is caused by the ignore_dup_key option. This is true in SQL 2005 and SQL 2008 as well as in SQL 2000. I wouldn't go so far as to say this part of the answer is wrong though: just that it risks engendering a mistaken belief that without this option SQL Server queries would be determinate.

I could make an argument about the ACID properties too (along the lines of climing that insert means something a little different when the target table has a unique index with ignore_dup_key - the statement has done all that was expected of it, so what is incomplete?) but that isn't a useful or interesting argument (ibuilding pitfalls into a programming language is a mistake so I won't go for that one).

Tom