No, it’s not, really.
The notion that tooling and language design are two separate concerns is a naive one: languages with fewer and more regular features are easier write tools for and the opposite is true. Go has excellent tooling support, since the language is very simple, and Scala has historically had poor tooling also because of some particularly complex features (from a tooling perspective). Think of macros, implicits, relative imports, to name a few.
We’re historically in a golden age for Scala tools: most tools are reaching maturity and adding new great features at a pace it was unthinkable 3/4 years ago.
I won’t comment on the feature from a user perspective, since I didn’t try it first-hand, but I’ll ask a question, for @odersky, mostly: have you considered the impact it will have on tooling, specifically code formatters like IntelliJ’s one and Scalafmt?
This is not something we can (yet) just try, since the lack of support for it, so I would at least expect an analytic approach where language authors and tool authors sit at a table and discuss the impact of a drastic change like this one.
The lack of good tooling has hindered Scala adoption since its inception, and now that we’re finally enjoying some amazing tools it would be foolish to set them back a few years because of a lack inclusion during the decision making process.
This stands in general for all features and all tools, but code formatting for significant indentation syntax is one where we have a shred of evidence from Python that it’s a complicated and largely unsolved issue even in a popular language where tooling is quite extensive.
Bottom line, I want to like this proposed feature, but I would be much much more re-assured if tool authors would be included more directly into the decision process.