Post in pre-embryonal stage!! Read at your risk :)

Foreign key inheritance @ the physical modeling level, when to?
1) non transferability @ conceptual modeling;
2) weak entity identification @ logical modeling.

tricks:
why replace natural structured keys with surrogate keys violating and missing conceptual constraints when you can keep both of them! You can define a natural structured primary key to implement the foreign key inheritance and enforce the non transferability constraint at the logical/physical level and on the other hand add a surrogate unique key to be used for afferent joins, just in case you identify that joining on a structured natural key is a performance issue that you can't accept.
In other words do the right thing for your model!
1)Define foreign key constraints on natural (and eventually structured) keys to maintain consistence with your conceptual model and implement a 'non transferability' constraint;
2)Join on an additional/complementary surrogate unique key (if strictly necessary).
If your physical model is well done (:maintainable and extensible) you can skip this second step and leave it as a later optimization prescription to be applied only in case the structured key joins will start degrade their performance for real.
Well sounds like I just implemented "Do The Right Thing" and "Premature Optimization" after all ;).

Additional thoughts that arise from this topic (it's just a post note for further topic development):
weakness of ER, lies of modelers: recursive relationships are often used to model hierarchical entities/structures. But hierarchical entities are weak by their nature, right? Don't you think? So how would you implement key inheritance on a recursive relationship than? No way...? Any idea? So "hierarchical ER data entities" are a lie? No way to enforce structural constraints of the hierarchy without special features. Alternative ER implementations than the self recursive relationship one then? etc.etc.