Some time ago we discussed in #9030 the possibility of throwing an exception by default when we find an Include() call that has to be ignored.

We decided against switching to throw by default because there are legitimate situations in which after a valid Include() is added to a query, further composition makes the Include() unnecessary, and we definitively don't want to throw in those situations. A common example of this is adding a call to Count() at the end of a query to compute the number of rows the original query will return.

However there is another situations in which Include() is called in a location which we either consider invalid or unsupported in a given release.

I am creating this issue to consider distinguishing between these situations and ensuring that we throw for the later.

I believe this aligns well with the philosophy of our query design in 3.0, in that it can help customers detect things that won't work earlier in development.

It can also help us evolve support for Include() in the new query pipeline more intentionally: we can start with support for basic scenarios in 3.0 and gradually add support for additional scenarios based on customer feedback, and with less risk of introducing breaking changes.

I also think addressing #12737 (revisit interpretation of path passed to Include() to allow partial matches) should help in reducing the number of situations in which Include() appears to be needed in weird locations in a query.