Scala SIP-18 and the Aftermath of Dissent

This post is about the recent semi-meltdown about Odersky's Scala Improvement Process nomination SIP-18. In a nutshell, Odersky claims a special language feature import would prove a beneficial means to establish the piece of mind that some of Scala's more advanced and "contentious" language features are not present in a given code-base. Suffice it say, this issue has a polarizing collection of pro's and cons.

The Pro's shortlist:

• If I know certain language features (Higher-Kinded Types e.g.) are bad for performance and will (in general) freak the Scala newbies on our team out, then unless our timid newbies see @import Higher-Kinds they can rest assured this is a Monad Free Safety-Zone.
• Odersky, in essence, argues that language constructs such as Existential Types are necessary for making sense of Java's Wildcard types, but application developer abuse of this feature can lead to brittle application code with compile-time type errors revealing themselves through some cryptic error messages.  SIP-18 could thus establish a  policy that could obviate a befuddling code-base evolution.
• Requiring an explicit import of categorical language features could seemingly produce a beneficial pedagogical side-effect.  Imagine this: after reading the few texts about Structural Types and still being clueless after the first few passes, a blossoming young Scala programmer throws his/her hands up and vows to return to the matter at a later date.  2 months pass, that day has not come, but the confidence is growing and our hero[ine] decides to copy/paste something from a blog that seems to address a current problem.  Without @import StructuralTypes at the top of their source, the compiler resolutely states you can't do "type T = {def receiveUpdate():Unit }" without explicitly enabling support for Structural Types.

Now the cons:

• Boilerplate, boilerplate, and more boilerplate.  This would add boilerplate everywhere (imagine what it would do to an innocent little Stack Overflow post.  Follow the link to SIP-18 discussion thread and search for "Rex Kerr" or "boilerplate").
• A language feature like this could actually cause inertia for the would-be Scala convert/adopter by creating a sense of an additional layer of complexity in a language already tagged as a paradigm mindbending, academically stuffy programming language.

After reading through the lively banter, I agree this should be a style-checker's feature and not some force that imposes itself into your daily interaction (over and over and over) with the language.  I mean, Martin Odersky is someone I kind of worship, so there obviously is some merit to this proposal, but in this case I respectfully disagree and really hope this doesn't make its way into my Scala-crafting horizon ever!  I was always a little concerned about how the language would evolve after 2.9.1 given what feels like it's father's abandoning affair with the monetarily alluring TypeSafe venture.  I didn't however, think it would lead to this much drama this quickly.