Description
In 3.0 we have limitations on how defining queries work. Main reason for that is to identify the user created custom projection as entity type. For keyless entity type it is circumvented due to it not using tracking. For keyed entity type it does not work (as mentioned as one of the problem in #17270).
If we look at #12668 then we decided that we don't treat entities created by user as an entity to be tracked. The main reason for this was incorrect assigned properties like key property missing. So what differs in defining query in that sense? If the custom projection in defining query used to create the object has incorrect formation then it would also fail (albeit differently). And even for keyless entity if the FK property is not computed properly then Includes wouldn't work correctly.
Another side of the coin in conjunction with #18457, defining query was invented in our pipeline as testing mechanism for keyless entity type in in-memory provider. If InMemory provider goes away then how much of value defining queries would provide to customer. For relational databases, likely they are mapped to database objects.
Lastly, defining query gives user a way to tell us that when a dbset is requested, replace it with this queryable. Removing this does not block that scenario fully. Instead of requesting dbset, user can define a property on DbContext which returns IQueryable and put the custom linq there. It just becomes user refactoring then first class concept in EF Core.