What should new VB features 'look' like, and how should proposals be presented?

Over the months that I've been following things here, the many suggestions for new features have varied greatly in quality, both in the quality of proposal, and in the quality of presentation.

I don't typically have very strong feelings about things. I can be a bit of a troll, and I like playing "Devil's advocate" on just about any topic. So my points on this forum are usually about getting people to think about aspects of proposals that are not obvious at face value.

But I do have a strong opinion on one thing, and that is that Visual Basic should be its own thing, independent of other languages, and only adopt paradigms and "cool new things" that will enhance the language as a rapid application development tool (for business and casual users alike) that encourages code that remains easy to maintain years later by other people. I think that abandoning "Feature Parity" between C# and VB was a good thing, because both languages were being constrained by the requirement that they be "cross-translatable", which diluted their individual strengths.

The things that have been a recurring theme for me in triggering responses to proposals are:

1) proposals that don't look like "VB" to me.

2) proposals that don't adequately address *how* they enhance the language.

3) proposals that I can't follow because they have inadequate examples, or examples that don't compile _(I understand that you can't compile a new feature, but many proposals are about new ways of doing old things, where the old things are pain points for the proposers, and having compilable examples helps make the point)_

So I have two questions/requests for discussion.

1) What should Visual Basic "look" like? There's a bit of a document on the proposal process [VB Language Proposals](https://github.com/dotnet/vblang/tree/master/proposals), but I haven't been able to find guidance on what the language's "style" and "look-and-feel" should be (or should not be). I think without this kind of guidance, you end up with bits of other languages being recommended for inclusion as VB elements in a non-VB way. For example, my pet peeve that I think was a mistake was the use of braces (curly/squiggly brackets) for variable initializers - `With` already had a perfectly acceptable `End With`, so

``` VB
Dim a = New SomeClass() With { .Name = "Foo", .Value = "Bar" }
```

looks like VB and C# had a confused baby, when
``` VB
Dim a = New SomeClass() With
.Name = "Foo"
.Value = "Bar"
End With
```

looks more like VB and, ignoring the `End With` (which the editor types for you), is *less* typing, and would have made converting from this easier:
``` VB
Dim a = New SomeClass()
With a
.Name = "Foo"
.Value = "Bar"
End With
```

2) Can we get guidance (perhaps in https://github.com/dotnet/vblang/tree/master/proposals) on *what* a good proposal should look like and what it should contain? Perhaps including some examples of good and bad proposals from this very forum (possibly redacted to protect the guilty). I frequent SQLServerCentral.com where they have some "forum etiquette" guidelines that advise on *how* to ask a question to get the best response [Forum Etiquette](http://www.sqlservercentral.com/articles/Best+Practices/61537/); perhaps something equivalent for vblang/issues would be helpful?

Perhaps even a couple of templates, around different types of enhancement?

I'll kick off the discussion with an initial thought on what should be in a proposal. Based on my experience with "user stories" that one might use in agile development, I think a proposal should read a bit like a user story:

> When I am implementing well-known pattern _XXX_, I find that I need to always add _YYY_, which is derived from _XXX_. This is tedious and error prone.
> If the compiler was able to implicitly add _YYY_, then my code would be more reliable, easier to read, and easier to maintain.
> Possible ways to do this include new attributes and/or syntactic sugar.