Major Section 3 currently states that an entity can be a member of at most one entity set. Given the ability to model entity type hierarchies this restriction seems rather unnatural: "Manager" is a specialization of "Employee", so it seems natural to have two entity sets "Managers" and "Employees", the former being a true subset of the latter, and a new "Manager" entity, POSTed to either set, would automatically appear in both.
Currently the only way to do that is to have an "Employees" entity set and a "Managers" function, with the drawback that the function is not advertised in the service document and thus not consumable in a hypermedia fashion.
Ok, try this one: a CRM service provides a Customers entity set, and a MyCustomers "view" which contains the customers for which the authenticated employee is responsible.
Ideally both sets would behave in the same way.
Currently I'm forced to model one of them as a second-class citizen called FunctionImport, limiting its consumption to read-only access, with the added hazard that not all tools on the targeted client platforms will support them equally well.
One way to do this would be through a (new) top level entity.
For example, I could define an entity name "Views" with navigation properties "MyCustomers", "TopCustomers", "PreferredCustomers", "DelinquentCustomers", "NewCustomers", etc.
I could then query my customers through ~Views/MyCustomers, POST to ~Views/MyCustomers, etc., but they would all still live in (and could be accessed through) ~Customers.
Good idea, just add a My entity to GET My/Customers 
Now we just have to add named entities to the service document to make them as prominent as entity sets.
On second thought I'd prefer to have "MyCustomers", "TopCustomers", "PreferredCustomers", "DelinquentCustomers", "NewCustomers" as first-class citizens directly in the service document, and entity sets are the natural construct for that.
We'd also accept POST on MyCustomers, which will automatically link the customer to the authenticated user.
Servers not being able to accept POST on multiple sets can use the Capabilities vocabulary and annotate exactly one entity set with an InsertRestriction that tells clients not to POST here, or simply only expose models with one entity set per type.
There's no need to restrict all servers.
Holding over to discuss at Zurich F2F.
proposal was:
"Remove sentence "An entity can be a member of at most one entity set." in fourth paragraph of section 3.
Servers not able to cope with this can always restrict the models they serve to only allow one "place of residence" per entity."
Consistent with offline discussion with Ralf and others, changing proposal to:
"Close without action"
Reasoning:
An OData entity is just a shadow of the "real thing" living somewhere in the domain model of an enterprise application. A "real thing" can cast multiple shadows, so it may show up in many OData services. Or multiple times in one service.
So I have NorthernCustomers(4711), SouthernCustomers(4712), EasternCustomers(4711), and WesternCustomers(4712). Each of four OData entities nicely belongs to one entity set. All of these sets use the same entity type, and that some of these entities have the same key value is all the indication a client will get that if it changes one of the four, another one will magically also change. We might give a hint by using the same edit link in entities with the same key, but probably that's not worth the trouble; let the infrastructure generate the canonical URL for each shadow.
Enter navigation properties: each of these customers belongs to a Country, and all Country entities live in a single Countries entity set. Which is not really a problem anymore: the Country navigation property in Customer and the Customers navigation property in Country just don't have a Partner attribute, and the latter either has no navigation property binding or binds to the Customers entity set where a third shadow of each "real thing" lives.
So the MEST problem seems to be solved and I think we can close the ticket without action; we have everything in place to model our situation.
OData is built around the assumption that the entity set plus the key values identify an entity within a service
I am very concerned that supporting entity instances in multiple entity sets is a much deeper change than simply removing the sentence that prevents it.
From the early days of the Entity Data Model on which OData is based, the concept that an entity lives in at most one entity set, and that its key uniquely identifies it within that set, has been a founding principle. I am very concerned about relaxing that principle.
The way in OData to get all employees who are managers is by explicitly casting, for example:
~Employees returns all employees, whether they are managers or not, and
~Employees/Sales.Manager returns only those employees that are managers