How are foreign key indexes helpful

ix_supplier_id and ix_manufacturer_id are not required; as long as you have the fields intended for foreign keys indexed by themselves (as in: (part.supplier_id)) , the names of the keys are arbitrary. You can also have them in composite indexes, but there must be at least one index of the whole field and nothing but the field. So help me DDL =).

The (lack of) documentation suggests that this behaviour is an implementation detail, and is therefore undefined and subject to change at any time.

This is in stark contrast to CREATE FULLTEXT INDEX, where you have to specify the name of an index to attach to -- AFAIK, there is no undocumented FOREIGN KEY syntax to do the equivalent (though theoretically, there could be in the future).

As mentioned, it does make sense that SQL Server chooses the smallest physical index with which to associate the foreign key. If you change the script to create the unique constraint as CLUSTERED, the script "works" on 2008 R2. But that behaviour is still undefined and should not be relied upon.

As with most legacy applications, you'll just have to get down to the nitty-gritty and clean things up.