I would support this type of extension, but while GETs are fairly low-risk with ambiguity there are certain questions I would like clarified since DELETEs (or even PATCHs or PUTs, for say, marking 11 emails as “read”) are generally destructive.
First, it isn’t clear to me how to handle a GET /comments?filter[post]=1,2 where the post with id 1 has been deleted or is not available to the individual requesting it (either unauthorized or forbidden). Should the whole GET result in a 400 level error? Should the request return only what it is able to and silently ignore the rest? Should the response do something more complex like assign 200s in the response body for the requested resources that are available and assign 400 level to those that are not?
It seems like a hairy issue. Generally speaking I default to 400-ing the entire requests, but some cases that isn’t pragmatic.
Now with a GET it isn’t as dangerous as a DELETE. For example, say there is an API for an accounting system and in order to support deletion of an expense that was incorrectly invoiced to a client a client issues a DELETE /transactions?filter[expense]=5&filter[invoice]=7 if the client only has permissions to delete the expense / transaction associated with the expense (since they filed it) but not the invoice or the transaction associated with the invoice, then what should happen?
I’d argue that in with DELETE the only thing that should be considered safe is ignoring the deletion of something that has already been deleted, otherwise the whole request should be rejected.