"So, given the announcement, which parts do you like, which parts do you consider unimportant and which parts are missing in your opinion?"

Things I love: Union/Intersection types. Any simplification of the type system with regards to type members. Any removal of special XML features. Any fixing of the travesty that is the collections library.

Things that are unimportant: "The type system will have theoretical foundations that are given by a minimal core calculus." A type system being theoretically sound doesn't interest me. What does this provide me in practice? Macros/Reflection (not that it isn't actually important, but unless Macros are central to your paradigm like in Lisp, they are a hack, who cares how hacky they are). Parallel collections.

Things that are missing: Structs. Structs. Real f'n Structs (granted this may be a JVM limitation but I'd trade nearly everything for them).

"Why do you think removing the arity limit is not interesting? What's your approach when interacting with databases, were tables with tons of columns seem to occur in practice?"

Because the only reason I can think of for having giant sized tuples is in a code generation scheme most likely for an ORM system. Code generation in an ORM system is generally a bad idea and it bothers me that an ORM system seems to have the ear of the language designers. When I encounter dbs with tons of columns, I fix the db using standard and proven SQL techniques like normalization, views, and stored procedures. I don't need or want a language crutch to get around those standards.

"What automatic refactorings would you like to see? Which impression do you have regarding ScalaIDE vs. the IntelliJ plugin?"

In an ideal world the Scala refactorings would achieve parity with the Java ones. As it stands currently, there are a fraction of the number of refactorings and they aren't actually safe, even on simple ones like rename or move. Using Eclipse is a non-starter for me. I prefer Vim or IntelliJ. That the Scala maintainers have a defacto standard that goes against my (and many other peoples) preference is a real problem. I would much prefer that the defacto standard was removed so that any solutions they came up with in the tooling space were of necessity workflow agnostic.

"If you had a few wishes about improving Scala in the future, what would they be and how would you implement them?"

The single most important next step for the Scala community is to come up with an idiomatic style. As it stands, if you open a library, go to a new company or even look at the standard libraries there is no single "right" way to write Scala code. For instance, lots of effort has been expended to enable type classes in the language but you can't use standard type classes to enable for syntax (to be honest I'd be fine with the removal of the for syntax entirely but understand that is a pretty out there proposition). A decision around what is and is not idiomatic code and a systematic rewrite of the standard libraries to follow that code is in order. Better yet, a program similar to Go format that just makes decisions about what is right or wrong is in order. The XLint/future features are a good start (not withstanding the neutering that happened with procedure syntax) but I would love to see something more aggressive.

Finally, Typesafe the company and Scala the community need clearer boundaries. It is troubling to me that the Akka/Play/Sbt/Slicks of the world get obvious preferential treatment when it comes to language prioritization. If you want to do something outside the norm in any of those functional spaces, Scala becomes hard to use (and in the case of Sbt they are actually internally inconsistent). I'd prefer a more hands off approach by the language that let the "market" decide the solution.