Unbeliveable error inserting child entity before parent

Here's the setup. Using a vanilla new 6.1.2.0 DevForce SL project.  Added  a new data model with just 2 entities from our domain model.  One is a parent table that has a single INT primary key (plus other columns but those don't matter). The second is a child table of the parent having a two-part key; both INTs.  The first part of the key is the parent table INT key and the second just a sequence number.  Child table also has others columns but again, they don't matter.

Parent Table: Table_B (you'll see why this name is important later)
Columns:
 MyKey INT NOT NULL
 other columns

Child Table: Table_A
 MyParentKey INT NOT NULL
 MyChildKey INT NOT NULL
 other columns

The child table has a database trigger that enforces RI (on SQL server 2008 r2 but this also happens on SQL 2008); you can't insert the child if the parent row doesn't exist.  Pretty standard.  There is NOT a database foreign key on either table. The domain model has an association between them.  Normal everyday stuff that works everywhere else except for these 2 tables.

Create one entity of each and add them to the entity manager (same as always).  Save Changes.  The relationship is populated correctly like any other entity relationship.

But, for some reason, EF or DevForce (not sure who) would always try to insert the child ahead of the parent and of course, the db trigger would catch it and throw an error.  I (and others) spent several days trying to figure it out.  Eventually I created a separate project to be sure it wasn't our custom T4s or our ancestor classes or our save inspectors (it wasn't).

So I created the vanilla project and after it failed there as well, I brought into the model another parent-child pair of tables.  Did the same thing and this time it worked in the vanilla DevForce project.  So what was different?

The names of the database tables seem to matter to either DevForce or EF (I'm guessing EF) when determining what order to generate inserts.  Oh I can see you right now shaking your head and saying, no that can't be.  EF looks at the EDM and figures out that child entity must wait for parent entity.   If only that were true.

Note that the Entity names in the model don't seem to matter.  I left them named the original names (which were also alphabetically backwards).  Only the physical data store backed table name seemed to matter.

Prove it yourself.  Add a couple of tables to northwindIB with a trigger on the child where the child sorts ahead of the parent.

This also was broken in the 6.1.2."e" patch build but we didn't notice it until we added the database triggers back in.

So if someone from DevForce could definitely say it's an EF bug, I'll go throw bricks at the Microsoft team building :-)  otherwise, please tell me there's some magic work around.