Nice. I did clean up and simplify my examples, hence the rogue :“$2”. Good that you caught this!
If you were not supporting the if within the query spec, we could easily branch that :ets.select into two functions each with their own query spec.
On the other hand, the for is valuable to support as it noticeably speeds up queries.
I do not have a strong preference on your question about syntax. Hopefully actual contributors to the language will chime in 
One thought that may lead you to consider one version vs another, the for here is used as an OR clause to match multiple task ids, however it could also be used to match multiple possible attributes (as in [ { :“==”, {:map_get, field, :“$1”}, … i.e. we’d be matching a key instead of a value. I imagine part of the appeal in writing the matchspecs in elixir is having key and value differentiation standing out more clearly.
A final thought: none of these pattern matches are terribly efficient since they require a full scan of the data sets, as opposed to lookup and match. We make up for it by optimizing our :ets cache set structures from flatter :dets stores (denormalized in multiple ways and updated only as needed). From my perspective, this is where the magic and difficulty lies, as opposed to writing the matchspecs. If the intermediate :ets caching and retrieval was done automatically based on our :dets storage structure and based on the way we ultimately query the data, that would be a lot of time and code saved indeed.
