0_namespacing.scss

mymodule {
  @at-root {
    .#{&}-header { ... }
    .#{&}-footer { ... }
    .#{&}-body   {
      a          { ... } 
      span       { ... } 
      p          { ... } 
    }
  }
}

1_namespacing_output.css

.mymodule-header { ... }
.mymodule-footer { ... }
.mymodule-body a { ... }
.mymodule-body span { ... }
.mymodule-body p { ... }

@chriseppstein Seems like what you are saying is that you'ved added a new construct (@at-root) for busting out of whatever nesting you are in and you've given SassScript access to the & operator. This allows for a more powerful way of constructing namespaced CSS, but doesn't really add a first class "module" concept. Am I following you?

What is the benefit of this approach over something more like the following?

$module-name: "mymodule";

.#{$module-name}-header { ... }
.#{$module-name}-footer { ... }
.#{$module-name}-body   {
  a          { ... } 
  span       { ... } 
  p          { ... }
  form       { button.#{$module-name}-button { ... } }
}

I like the @jlong approach and I was thinking the exact same thing.

Same here, I like the @jlong approach, more easy to use

Sass doesn't enforce a particular way of writing CSS and we try to provide approaches that feel natural to develop with. The definition of a "CSS module" doesn't exist in any sort of formal way and neither will it in Sass. When we develop a first class module concept it will be for organizing sass files to ensure namespace collisions can be managed. Feel free to use the approach that @jlong has suggested. It works now. However, many people have wanted a way to use the stylesheet context to define their concept of a module and that is what we are aiming to provide here.

Please keep in mind that these feature can be used within mixins that accept content blocks, etc. So an "@include module($name) { ... } " concept could be defined very easily. I think we will quickly find some very nice ways to create useful abstractions with this set of features. And as I have pointed out elsewhere, the @at-root directive and script access for & have benefits beyond just modules.

Has there been any discussion to do something more unobtrusive? For me, the value of namespacing comes in when integrating, where it's not possible or edit and maintain the source. For example, bootstrap and foundation both use .table which to me is too generic.

With styles.css:

.table {
  color: red;
}

Then

namespace mymod {
  @import "styles.css";
}

Would compile to

.mymod-table {
  color: red;
}

Can someone please give another example of how namespacing might be used--thanks @aceofspades, I just would like to see it in another context.