Hi Katerina, thanks for the thorough response.  I'll try to comment on why I think this is, in fact, a very useful and architecturally sound feature request.

As for auditing/logging, I agree with much of what you say.  An 'AuditEntityBase' base class seems like a wonderful idea.  However, we are dealing with a legacy database as well as other client applications that we need to peacefully coexist with.  So adding 2 extra columns to hundreds of tables is not something that would really go over well.  Side note: we do have an interface that contains ModifiedDate and ModifiedUser and do use that in the same way you suggest - but we are only able to do this because those fields already existed in our database so it was an easy one for us to 'do right'.  Unfortunately, sometimes a legacy system forces you to do things that aren't how you would do it on a brand new project

I've already digressed a bit because, as it turns out, our application uses database triggers for most of our auditing and logging.  It's very straightforward logic that I have no problems doing in a trigger with a bunch of boilerplate and unchanging SQL.  There's not a lot of complicated business logic and, as a bonus, all our client applications get that auditing/logging behavior 'for free' without having to 'reinvent the wheel'.  Also, updates to our database through 'not-so-official-methods' (e.g. ad-hoc SQL scripts) end up triggering the same audit/logging logic so there is no way to bypass it.

As you might have guessed, I'm not requesting this feature in order to perform logging or auditing.  Nearly all of my use cases involve times where I need to know the auto-generated primary key of an entity and use it to update the database in the same transaction as the original save.  The specific cases are a bit domain-specific, but I’ll try to give some simplified examples.  Imagine this kind of scenario:

Imagine we have a table that contains 'email delivery requests'.  The table functions as a queue where our application can add requests and some other system picks up those requests and services them by sending emails.  So maybe after a new Customer is saved, we want add a new entity such as the following: new EmailDeliveryRequest{Subject="New Customer Created", To="Bob", Body="There is a new customer with ID 123 that you should do something with"}.  How would we do this with DevForce...let's look at the existing options:

1. We add the new EmailDeliveryRequest entity before the save because we don’t know what the customer's ID will be.  
2. This isn't the kind of thing that we'd want to put in a trigger because the logic can get complicated (some new customers go to Bob, other ones go to Sally, etc.).  And I very much dislike having non-trivial logic hidden away in SQL where I can't see it, test it, etc.
3. We most certainly want the request to be created within the same transaction so we don’t have to worry about a Customer getting saved correctly but then something going wrong when we try to save the EmailDeliveryRequest.  So trying to make two SaveChanges calls from the client is not an option.
4. We can't just make an association in our model and have the temporary-id fixup logic take care of it since the ID ends up stuffed in a string so DevForce/EF would have no chance at figuring it out.
5. Write a stored procedure where we pass Subject/To/Body and it adds a row for us.  Then we can call this procedure as part of the save process within the transaction.  This ends up being the only viable solution so we go with it.  But then we have a bunch of stored procedures that exist solely to do something embarrassingly simple like add 3 values to a table somewhere.  Not very fun.  A related solution would be to drop down to low-level ADO.NET, raw SQL or something like that to do the INSERTs.  Again, not a very fun thing to do.