Materializing entities with unknown type: the DO4 way - the addenum

Recently I wrote Materializing entities with unknown type: the DO4 way. And today I remembered about one more important case:

6. If type discriminator (TypeId) is included into Entity.Key, there will be no type-related lookups. On the other hand, currently we anyway try to fetch the entity to ensure if it exists or not.

So inclusion of TypeId into Key affects on fetch behavior (Key resolution):
- If it isn't included, and no TypeId is cached for this key, fetch request will "touch" only hierarchy root table.
- Otherwise it will touch the precise set of inheritance tables.

But how this is related to materialization behavior? Of course, if this type of Key mapping is used, we can provide an instance of an object any Key refers to without any lookups, and load its field values further. But currently we don't do this. This isn't absolutely necessary, since we anyway provide a way to read Key corresponding to any reference property without materializing the Entity it belongs to via Persistent.GetReferenceKey method; on the other hand, in such cases we can allow this behavior - simply because it worth nothing in this case, and this is safe?

So what do you think, must we add this feature? E.g. it may work if [Association(LazyFetch = true)] is applied to reference property and reference key includes TypeId. Note that the only benefit of this is that you can access Key, TypeId (thus type as well) and IsRemoved properties of such entity without hitting the database. On the other hand, Persistent.GetReferenceKey provides the same information in this case (IsRemoved = key!=null; TypeId = key.TypeId).

So... Must we implement this?

P.S. Earlier I published information on DataObjects.Net code coverage. Quote from the article: "Tests for Xtensive.Storage project are performed in 3 (provider: Memory, MS SQL, PostgreSQL) * 3 (different inheritance schemas) * 2 (TypeId is included / not included to any reference) = 18 configurations at all". So:
- The case when TypeId is a part of reference is fully tested
- It's actually quite easy to write an IModule adding TypeId to all the Keys. See TypeIdModifier class source is Xtensive.Storage.Tests project for ideas on how to implement this.