I didn't notice that we allow using the table name as filter even when the alias is present. This is the only test that mentions this, but I don't think this is expected, right?

From now on, this would fail with an error like:

GET /projects?id=eq.1&select=id, name, the_tasks:tasks(id, name)&tasks.order=name.asc

{
  "code":"PGRST108",
  "details":null,
  "hint":"Verify that 'tasks' is included in the 'select' query parameter.",
  "message":"'tasks' is not an embedded resource in this request"
}

If this change is OK then more info to the hint would be needed like: "If it has an alias, then use it instead of the resource name".

If using the resource name as well as the alias is expected, then this would be a breaking change and the solution would be different. Maybe throw an error when there may be ambiguity (like in #2529).

From now on, this would fail with an error like:

This would also fail for filters, limits, etc.

As long as you're only using one embedding for the same table, but with an alias, this is a working query right now. So, I'd say we only fix this in a major, otherwise people can't update to the latest patch without risking to break something that works.