The second is template lambda and templates have void type.
What you suggest here?

In D template functions become functions if they are passed where
the D compiler can infer their full type. This is correct code:
void foo(int function(int) f) {}
void main() {
foo(a => a * a);
}
Bye,
bearophile

To consider opening an enhancement request, are you able to explain us
why?

It is just embarrassing if it does not work. Similar things work even in
C#. Of course, it is harder in D because the type system is Turing
complete and stuff.
I think we want to support things like:
[1,2,3].map(a=>2*a);

And is it possible to implement it? :-)

Yes; in fact it almost works satisfactorily in my home-grown front end
already.
As most of D compilation, it is undecidable, but the following heuristic
should be fine:
1. Resolve and fix explicit template arguments.
2. Infer types from arguments. Unify. Do not consider known lambda
return types at this point.
3. Analyze lambdas whose parameter types are known. Fix those types.
4. Resolve lambda return values where known. Unify.
5. Repeat 2-4 until fixed point is reached.
6. Use default template arguments.
7. Repeat 5-6 until fixed point is reached.
8. Check if everything became known and if the argument types are
actually compatible with the inferred signature.
(Where 'fix' means, if the type should later be unified with something
that is not the same type, fail instantiation.)
Furthermore, probably it should treat curried lambdas a little more
cleverly than the above. It may be argued that this is too complex. :o)

Even if they are trying to speed up Scala compilation, it's much
slower than Java/D compilation, because the Scala type system is
very complex and refined and the compiler has to work a lot.
If the D type system gets refined as we are discussing here,
maybe the compilation speed of templates will be reduced a
little. I have no idea if this is true, and how much.
Bye,
bearophile