I wasn't able to find an issue for this bug but did see some references to it being a known issue on Stack Overflow. I've attached a sample project to reproduce the problem and tested with similar results against both stable EF5 and latest nightly build of EF6.
Comments: I looked a bit more at this and came to the conclusion that this could be solved in a relatively inexpensive way by "lifting" all the FK properties in derived tables to the base table. Lifting an FK would mean that a required FK on a derived table gets "re-mapped" to a nullable FK in the base table. The base entity will still not contain the FK, but the mapping will specify an IsNull="true" condition for the column, while the derived table will map the column to the property as always and can include an IsNull="false" condition. This mapping currently cannot be expressed in either Code First or the EF designer because of limitations on them but it is possible editing the XML artifacts (the attached EDMX files illustrate the approach). This would allow us to generate a cascade delete from the principal side to the dependent base table and another one from the dependent base table to the dependent derived table in the database DDL. Of course when implementing a solution like this we need to consider the fact that enabling this default would break existing applications using TPT with the current conventions. We will need to consider mitigations for this, such as new non-default conventions, new conventions sets, etc. I also started some thinking about another approach, consisting in adding just enough DML-like capabilities to EF so that we can issue a DELETE statement based on a FK match (as opposed to a PK match) so that we can issue DELETE statements for both the dependent base table and the dependent derived table. The approach however seems to be quite complicated: the challenge is that because of referential constraints in the database the rows in the dependent derived table would need to be deleted first, unless we can rely on the existence of a cascade delete between the base dependent table and the derived dependent table. If this cascade delete exists, we can issue a delete for the base table, that joins into the derived table to find the rows with the right FKs. All in all it seems that we could not completely stop relying on cascade deletes.
Comments: I looked a bit more at this and came to the conclusion that this could be solved in a relatively inexpensive way by "lifting" all the FK properties in derived tables to the base table. Lifting an FK would mean that a required FK on a derived table gets "re-mapped" to a nullable FK in the base table. The base entity will still not contain the FK, but the mapping will specify an IsNull="true" condition for the column, while the derived table will map the column to the property as always and can include an IsNull="false" condition. This mapping currently cannot be expressed in either Code First or the EF designer because of limitations on them but it is possible editing the XML artifacts (the attached EDMX files illustrate the approach). This would allow us to generate a cascade delete from the principal side to the dependent base table and another one from the dependent base table to the dependent derived table in the database DDL. Of course when implementing a solution like this we need to consider the fact that enabling this default would break existing applications using TPT with the current conventions. We will need to consider mitigations for this, such as new non-default conventions, new conventions sets, etc. I also started some thinking about another approach, consisting in adding just enough DML-like capabilities to EF so that we can issue a DELETE statement based on a FK match (as opposed to a PK match) so that we can issue DELETE statements for both the dependent base table and the dependent derived table. The approach however seems to be quite complicated: the challenge is that because of referential constraints in the database the rows in the dependent derived table would need to be deleted first, unless we can rely on the existence of a cascade delete between the base dependent table and the derived dependent table. If this cascade delete exists, we can issue a delete for the base table, that joins into the derived table to find the rows with the right FKs. All in all it seems that we could not completely stop relying on cascade deletes.