Having it officially pushed by Google would mean better tooling and more Scala-ish APIs.
The beauty of both Swift and Dart is that they are very "light" languages. You can read a piece of Swift/Dart and see what it's supposed to do immediately. Most people with a JS/Ruby/Python/Java/C# background can immediately see what's going on, and probably quickly pick it up. Yet they still provide productive modern language features. Scala's learning curve is much greater.
Yes, Swift is pretty much missing the FP parts, but isn't that an argument about familiarity, not simplicity?
Preventing bad code is a lot harder than that.
It's perfectly possible to use code which uses "powerful trait-based OO programming, its functional style with routinely chaining monad after monad, and implicits everywhere" without having to know that part of the language.
Just have a look at their mailing lists. Or the issues they are currently struggling with.
It seems that today's Groovy mainly exists for its owning company (which seems to change every now and then) to sell training.
But considering Google's taste for mediocre languages, Groovy would fit right in next to Dart and Go.
Groovy's dead for JVM scripting, and Grails is losing adoption share rapidly, but it's rebounding as the DSL in Gradle. I've yet to see a Gradle build script that actually drops out of the DSL to use Groovy to do any programming, though - perhaps Gradle's too good at what it does.
Developers like Gradle because it has Maven-depth functionality with a JS/CSS-like syntax. Gradle would have more uptake if it enabled developers to plug in other dynamic JVM languages, e.g. JRuby, Jython, Clojure, Nashorn, JDart. Even Scala's dynamic mode might work.
I've looked briefly at Gradle's source and Groovy seems to be entangled deeply in it - Gradle even manipulates Groovy's AST all over its source. I suspect Gradle was set up with the specific intention of promoting Groovy and making it difficult to work with other languages, despite the quote on gradle.org: "We happily support any community effort to create additional build script engines".
Gradle needs to expose an API for its use like other products do if anyone is going to believe they're not going to change their source to prevent other build script languages being plugged in, just like Groovy 1.7 and 1.8 source changed to give Groovy++ and others the runaround around 2010 / 2011. But I suspect the same people behind that are ultimately behind Gradle.
That's why I have no interest in Scala. I prefer languages with only a handful (or less) of "good stuff" that you can then build on top of.
Apart from that, Scala is built on an impressively small amount of orthogonal concepts (at least compared to stuff like C#, F#, C++, OCaml, etc.) despite what all those "experts" on the Internet say. :-)
But I also think standards should reflect the progress made in the last few decades and shouldn't pretend that it's still 1960. Otherwise, things like Go happen.
So, yes, functional languages these days should probably require types (not specific to functional languages, just a general requirement to throw out all untyped languages without wasting time), typeclasses, and at least one of higher-kinded types, linear/dependent types, type families, or something like the fusion of type-level and value-level programming like in Idris.