As Sass' popularity began to grow, competing CSS preprocessors began to emerge. A trend that clearly showed that not only Rails developers were interested in these ideas.
New languages, specifically LESS and xCSS, showed up on the scene and share many, but not all, of the same features of Sass. What made them stand out from Sass was their adoption of the standard CSS syntax. Developers using languages such as PHP or .NET were not yet used to the idea of indentation languages like HAML and Sass. Adding to this, UI developers who's bread-n-butter is CSS, were not to excited about Sass' syntactical approach either.
Sass found itself at the crossroads. CSS3 was gaining in strength and popularity. New features were being added to the spec at lightening speed. Not to mention, code examples that could quickly be executed in other competing languages required conversion in order to be used with Sass. Sure there was a quick command line tool to convert CSS to Sass, but those who were bothered by the syntax typically were not fans of the command line either. Use of the standard CSS syntax by competing languages made them more desirable to a new audience of preprocessor users. Frankly, Sass' original syntax was being viewed by some as a barrier to the language.
March 31, 2010, Nathan Weizenbaum announced Sass 3 beta release the new CSS-superset syntax to be known as "SCSS" or "Sassy CSS". It was becoming clear that Sass had outgrown it's humble beginnings as simply an aesthetic alternative to CSS. Sass was becoming a language all of it's own. A language that has it's own path and requires an approach that is not exclusively tied to HAML. This announcement, and the work that followed it, was in direct response to the changing world. Whereas HAML and the whitespace writing style was leveraged for Sass adoption in the beginning, SCSS was to intended to bring in a much larger community of CSS developers that Sass was eager to have.
The addition of the SCSS syntax was a major undertaking by the core team and one that was fully embraced. Even to the extent that the Sass reference docs were rewritten to use the new CSS extension syntax. A brief summary of the work done is as follows:
It is important to note that the inclusion of the SCSS syntax did not mean the deprecation of the original whitespace syntax. Nathan Weizenbaum recognizes the indented sass syntax is here to stay that a large part of Sass' initial success was due in part to people who do not prefer the standard CSS syntax and he was not about to alienate a large portion of it's users.
Be it the original Sass syntax or the newer SCSS syntax, the good news is that you don't really have to choose. Positions, personalities and preferences will vary greatly as to how to write Sass. Maybe you choose to only write Sass, or maybe you write only SCSS, or maybe you do a little bit of both? Due to the complete compatibility of the two syntax, .sass files can live harmoniously with .scss files in the same project.
I should note, the Sass whitespace syntax and the SCSS syntax cannot live in the same file. That is it's only limitation.