What is your evaluation of the proposal?
+1 -- for the style-guidelines
+1 -- for a format-tool using LibSyntax or SwiftSyntax (I don't know much about the one proposed however)
Is the problem being addressed significant enough to warrant a change to Swift?
It sounds beneficial but not urgent, so assuming development doesn't impact higher priority efforts it seems like a good addition.
Does this proposal fit well with the feel and direction of Swift?
Yes. Swift has declared itself to be opinionated. Ideally it would make adhering to its style-guidelines easy, but leave other styles possible.
Judging beauty and elegance of style is subjective, but there are big benefits if style-guidelines are predictable and consistent.
The recent embryonic discussion of Swift in a non-English language may not ever come to fruition, but it shows Swift-interest from people whose native tongue isn't English. IMHO. even before becoming fluent with Swift's keywords, predictable, consistent styling helps to visually reinforce and aid learning.
Even if you're an experienced Swift developer, consistent style-guidelines that expose an unexpected formatting can help diagnose problems with code validity.
Assuming the code is valid, predictable style-guidelines also reduce clutter and let you focus just on what the intent of the code is.
Unexpected formatting is cognitive noise, and as style-guidelines become more universally adopted, the more consistent ones expectations become, and the more cognitive-noise can be reduced.
If you have used other languages with a similar feature, how do you feel that this proposal compares to those?
I hesitate to bring this up, but if you're familiar with the wealth of BASIC environments on old 8-bit computers (TRS-80, Apple II, etc), those are simple examples of style-guidelines that most would say were ugly, yet they were still helpful through their consistent enforcement.
The platform's style wasn't a requirement for valid entry, but the BASIC environments enforced their platform's style after entry. A motivated developer could still use other tools to develop with a different style, or toy with tricks in code to appear to vary from the platform-style. Despite those options, most programmers got quite accustomed to predictability of a platform style. So as ugly as the style was, it helped debugging because of the standardization. Even in printed magazines or books, one would find the ugly-but-predictable platform-style even when they could have changed to more attractive style-guidelines.
BASIC environments aren't terribly comparable to Swift; I merely thought it was relevant to mention the benefits effects of even an ugly set of style-guidelines.