This is exactly how I feel about this topic. I like that for is getting map_reduce capabilities, but I dislike the let name. First, it introduces a completely new terminology for something we already have. But more importantly, this terminology misses the main purpose of such comprehension (to map and accumulate). So from that standpoint, for map (same as plain for for backwards compatibility), together with for reduce and for map_reduce seem perfect to me.
I don’t share the interpretation that for means map. To me a construct like for x <- 1..3, x != 2, ... always reads as “for every x in 1..3, x not equals 2, … do something”. In other words, IMO the word for communicates about the traversal, not about the outcome of such traversal.
For completeness, I also privately proposed three separate special forms: map (current for), reduce, and map_reduce. However, José pointed out that this would break a lot of the existing code. Perhaps if Elixir was designed from the ground up that would make sense, but as it is, for map, for reduce, and for map_reduce are the options I like the best, both as the user of the language, but also as a mentor and a book author who will have to explain this stuff to other people 
