What is your evaluation of the proposal?
+1. Especially for the official style guidelines (elaborated at the end).
Is the problem being addressed significant enough to warrant a change to Swift?
Oh yeah. If we think time is a limited resource, an official style guide will save time, and the saving scales with popularity of Swift -- then adoption of a this proposal will be priceless.
Does this proposal fit well with the feel and direction of Swift?
This fits right in with Swift's API Design Guidelines, which in a lot ways are unique and outstanding among programming languages.
If you have used other languages with a similar feature, how do you feel that this proposal compares to those?
gofmt is the target for comparison. In Go communities, coding style is rarely discussed or even thought about. Programmers type in valid code however they want and formatting is done automatically. The result is they spend more time building what they care about.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Read original pitch, discussion of original pitch, this proposal. Have worked professionally with Swift from 1-person team to projects that involves 70+ and growing number of Swift programmers, where an style guide exists since the beginning the project, enforced by linters and code reviews rigrously, with only limited success.
Notes on official style guidelines
Among the two things proposed, I believe a set of official guidelines with no ambiguities in their recommended coding styles, will be more important than the tools that help enforce them.
I doubt anyone really questions the value of code style consistency in a collaborative environment. So having a guideline that everyone should follow for a project is good (lots of discussion in the past were centered around this point, let's get that out of the way).
There is an unique property of an official style guide that I want to point out.
Today, enforcing a guideline in any kind of scale is a doomed effort, assuming the goal is 100% conformance. The fundamental issue is this: people have different backgrounds. They learn Swift in different projects, they grow their syntatical preferences from their personal experiences with a diverse set of languages through a number of years. When you ask people to follow guidelines of the project, they'll at best spend time to learn, discuss and adapt to it. And whatever things your guidelines don't cover, they'll apply their own interpretation. As programmers, our instinct then, would be to enhance said guidelines -- good luck bringing that up to your team/community and have fun doing that!
So, if you value consistency in any particular project, the only way to achieve it in a future-proof way, is to have consistency community-wide: ask everyone who comes through the Swift door to learn the official reccommendations once and only once. Point to the official text if someone makes a mistake (assuming that's possible with tool enforcement).
From a individual perspective, not having to learn or worry about a new set of guidelines when contributing to a new project is nice. It means we get to focus on things that matter. I hold the belief that "readability" is an over-weighted concept. Beyond a threhold of consistency, anything can become readable very quickly (even Lisp, Haskell, ASM!), this is an ability that we all possess.