Now that #15032 is merged, here are the main remaining steps discussed in #8450, roughly in order that they should be implemented:

• Improve output type-computation in broadcast to be at least as good as map (broadcast picking incorrect result type #4883). The trickest part is the ongoing discussion of what to do in the empty-array case (see Coherent map and comprehension, the imminent death of type_goto #11034).
• Deprecate @vectorized functions like sin(x) in favor of sin.(x). Deprecate functions vectorized via @vectorize_(1|2)arg in favor of compact broadcast syntax #17302
• Parse operators like a .+ b as broadcast(+, a, b). (See also support many more Unicode infix operators #6929 (comment), Allow users to define "dot" vectorized operators. #14544, and parse more dot operators, parse .= with assignment precedence #17393.) Existing overloaded functions .+(a, b) = ... can be deprecated in favor of overloading broadcast(::typeof(+), a, b). make "dot" operations (.+ etc) fusing broadcasts #17623

More speculative proposals probably for the 0.6 timeframe (suggested by @yuyichao):

• Define nested f.(args...) calls as "fusing" broadcast operations at the syntax level. For example, sin.(x .+ cos.(x .^ sum(x.^2))) would turn (in julia-syntax.scm) into broadcast((x, _s_) -> sin(x + cos(x^_s_)), x, sum(broacast(^, x, 2))). Notice that the sum function (or any non-dot call) would be a "fusion boundary." The caller would be responsible for not using f.(args...) in cases where fusion would screw up side effects. fusion of nested f.(args) calls into a single broadcast call #17300
• Define x .= ... as "fusing" calls to broadcast!, e.g. x .= sin.(x .+ y) would act in-place with a single loop. Again, this would occur at the syntax level, so the caller would be responsible for avoiding function calls with problematic side effects. (See make .+= et al. mutating #7052, but the lack of loop fusion at that time made .+= much less attractive.) treat .= as syntactic sugar for broadcast! #17510