To talk about minor version numbers is to miss the point, I think. Scala 2.10 brought more new features than java 7, and scala 2.11 will bring more new features than java 8. It's just happening faster.
The problem is that Scala's leadership is conflicted: you have Typesafe trying to turn it into a product and the researchers inside Typesafe more focused on producing papers for their academic careers, and therefore steering the boat in a direction that conflicts with pleasing new users.
Scala 2.11 is modularization (meh), Scripting Engine support (cool), REPL improvements (ok), and Async/Await support (YES!). I wouldn't want to lose those in favor of sitting still.
I mean, when people talk about "Scala needs fewer features" what is it exactly? XML? Well that's being modularized out in 2.11. Still seems like a pretty weird thing to stake a claim on though. What features exactly need to be stripped?
And BTW, the IDE support (in IntelliJ at least) is pretty good. Maybe not amazing, but coming from ST2+Ruby to IntelliJ+Scala it's night and day. Doesn't seem to be nearly the wasteland to me that some comments imply.
Macros come to mind. It's a feature that completely circumvented the SIP (and was later retrofitted into it), which is still heavily controversial inside scala-internals to the point that we're still not sure whether they will ever be officially part of scalac and which will probably never be used by more than a very tiny minority of Scala users.
They took months of work (which could have been put to better use, e.g. IDE support), mostly done with little transparency and which started generating papers for conferences before the project was remotely close to a prototype.
This kind of project would never have seen the light of day if the language was led by a company focused primarily on users and sound engineering.
As you imply, macros are labelled experimental, which means that you have to enable them explicitly. Having experimental features is Scala's way of reconciling a vibrant open source community with the stability needed for enterprise use. Needless to say, we do not recommend use of experimental features in enterprises. They are good for playing around with interesting new concepts and sometimes they do lead to something which is a win, such as the beautiful async/await library that will ship in 2.11.
Speaking of target audience and usefulness. Even before being officially released, macros have attracted attention of popular community libraries and tools (e.g. SBT, Akka, Play, Slick), and later on we got even more people on board [1]. Therefore, even though not many people are writing macros, a lot of Scala developers are, sometimes even unknowingly, using them.
That's I think is the best thing about macros in Scala - natural integration with other language features, to the extent that people aren't even aware that they are using macros and not regular functions or implicits or whatnot. Surprisingly many features can be empowered this way, giving rise to new and effective ways of solving development challenges [2].
Speaking of the future status of macros. Half a year ago, we had a joint EPFL and TypeSafe meeting where we decided to stabilize a subset of macros (so called blackbox macros [3]) and include it as an official, non-experimental language feature by 2.12. Indeed, at times we have fierce debates on our mailing lists about this or that esoteric macro flavor, but that concerns only my research activities [4], not blackbox macros, which have reach unequivocal approval at scala-internals a long time ago.
This brings me to the next point - transparency of development. For the entire duration of my doctoral studies at EPFL that begun in Sep 2011, we were always open with our plans, welcoming feedback and actively answering questions on the mailing lists and stack overflow. Some of the most successful reflection and macro features are there only because of our close collaboration with the community, and I'm very grateful to everyone who has participated and is participating.
Finally, the thing about generating papers is just untrue. Sure there are people who do their research using macros, but if you take a look at the list of my publications, you'll see that over the two years that I've been a PhD student I have authored zero conference papers. This is the cost of seeing through an implementation of a feature in an official language release, addressing the feedback of early adopters, and then maintaining it as it's being used in production. But anyhow I don't mind how it turned out, because I'm very glad that more and more people are picking up macros and finding them useful.
[1] http://scalamacros.org/paperstalks/2013-06-12-HalfYearInMacr... [2] http://docs.scala-lang.org/overviews/macros/usecases.html [3] http://docs.scala-lang.org/overviews/macros/blackbox-whitebo... [4] http://docs.scala-lang.org/overviews/macros/paradise.html
The macros support included in 2.10 is pretty basic and difficult to use, but with annotation macros and quasiquotation in macro-paradise those issues are eliminated.
And who are you to determine what gets priority amongst open-source devs? Does macro support make scala a worse language? Are you upset that an unpaid researcher (not an employee of typesafe) decided to spend time implementing the macro system instead of working on the IDE?
We (Typesafe) are using macros in our own projects, so the small investment in helping out with their development has largely been paid off because they essentially give us a lightweight compiler plugin mechanism. Users need not be aware macros underly, say scala-async.