If you hadn’t heard already last week at BUILD we announced the PUBLIC release of a Preview of the next version of the Visual Basic language and code editing experience powered by “Roslyn”. You can download this preview and install it on top of Visual Studio 2013 today!

I’m excited to let you know that included in this is a preview of a new language feature we’re considering that let’s you Select Case on the type of an object like this:

A feature like this sounds very exciting and we’ve actually been discussing it a lot lately how we could possibly do it. We have a number of syntactic options one of which aligns more with the way Catch statements work today:

Like Catch this captures the value in a new variable so you have a strong-typed reference inside of the Case block. We’ve also discussed supporting a When clause like Catch statement exception filters:

If you hadn't heard already last week at BUILD we announced the PUBLIC release of a Preview of the next version of the Visual Basic language and code editing experience powered by "Roslyn". You can download this preview and install it on top of Visual Studio 2013 today!

I'm excited to let you know that included in this is a preview of a new language feature we're considering: Select Case on type. It gets *really* close to what you're asking for - it just requires using a different name (the individual cases can have the same name, they just can't be the same as a variable or parameter that's already been declared):

I have to say my automatic strong typed feature would not be safe sometimes but your "Catch style" syntax would be safe.
The following situation would cause an unexpected run-time error instead of a compiling error:
State 1 with a single type condition without problem:

Case CheckBox
It.Checked = True

State 2 with a new type condition and a forgot assignment with the Checked property but there would not be compiling error unfortunately because of the late bound:

Same with your "Catch style" syntax.
State 1 with a single type condition without problem of course:

Case chk As CheckBox
chk.Checked = True

State 2 with a new type condition and a forgot assignment also with the Checked property:
(provided that you would like to also implement a type-list feature with the Case statement)
In this code, there would be a safe compiling error: 'chk' is not declared

Case CheckBox, TextBox
chk.Checked = True

----------------------------------------------

Nevertheless in my opinion, the It-reference would be steel useful but without automatic strong typed feature.
In other words, the type of the It-reference would be always same as the type of the testexpression.

@Anthony
The strong-typed reference and the When filter ideas are very good and useful.

A strong-typed reference example based on your syntax:

Select Case sender
Case btn As Button
btn.Text = "Ok"
End Select

Because of the declaration, I think, it is not clear that the selection is a type selection.

In my opinion, the solution would be a reference for the testexpression in the Select block.
I have two kind of syntax for the strong-typed reference idea.
1.
The following syntax would have a new reserved It-named keyword what would cause a breaking change unfortunately however it would be the ideal syntax:

Select TypeOf sender
Case Button
It.Text = "Ok"
End Select

2.
And a similar idea without breaking change:

Select TypeOf sender Alias It
Case Button
It.Text = "Ok"
End Select

If the type of the testexpression (sender) is an object and
there is only one type name after the Case keyword then
the It-testexpression-reference would be a strong-typed reference automatically by the single type name.

The TypeOf keyword would sign to the compiler that the default and hidden operator would be the TypeOf...Is operator in the background between the testexpression and the Case-type-item(s).

The Select-TypeOf statement would be optimized for type checking but value and object equality checking also would be used with the It-reference.
The AndAlso, Xor logical operators would be used in a Case-item but exclusively with the It-reference.
The When filter also would be supported.

In both concepts, the It-keyword would be a reference of the current testexpression.
In both concepts, the It-keyword would substitute the Is-keyword in the current Select block.
In both concepts, the It-reference would be used only inside its own Select block but not in a nested Select block.
In both concepts, the using of the It-reference would be same.

The Alias extension would be an optional declaration.
After the Alias, the It-keyword would be a fixed named variable (not a reserved keyword).
Actually, the optional ... Alias It ... would be a temporary compromise without breaking change.
In the future, the ... Alias It ... and the Is-keyword would be removed from the
Visual Basic to use the more ideal It-reserved-keyword (1. idea).

advantages:
- redundancy-free type checking
- clear syntax
- regular Visual Basic syntax
- automatic strong-typed reference
- more effective development with the It-reference
- reusable code with the It-reference
- AndAlso, Xor logical operators can be used in a Case-item
- When filter can be used
- easy to learn and use (... Alias It ... by intellisenese)
- easy to read
- etc...

Without the When filter it should redesign the previous code to an If structure what would always cause a very redundant code.

Even, I can also imagine the next with the using of the It-reference in a Case-item.
It would be very interesting and useful sometimes but perhaps it would reduce the easy code reading compared to the present Select structure.
However, a similar If structure often would be even worse in this context.

- AndAlso operator using with a property of the It-reference:
(this would not be solved with the When filter)

@Guillermo
The most important feature of a Select structure is the redundancy-free selection.
Your code is redundant.
The True/False checking is practically equivalent to an If structure what would be also redundant.
In other cases, some redundant OrElse operator can be avoided but there is no other benefit.

Thanks for the status update.
It's a very good news.
I'm sorry that I did not answer yet but there are a lot of question:
What syntax would be compatible syntax?
What syntax would be the best without breaking change?
What syntax would be the best with breaking change?
What syntax would be the most familiar Visual Basic syntax?
What syntax would be the most most regular Visual Basic syntax?
What syntax would be the most comfortable syntax?
What syntax would be the most readable syntax?
What syntax would be the most learnable syntax?
What syntax would be the most usable syntax?
What syntax would be the most effective syntax?
What syntax would be the most appropriate for the future?
for example:
- real testexpression reference in the Select-Case block
- AndAlso operator in a Case item

What syntax would be the best based on the frequently used operations?
One common syntax or (and) three kind of syntax based on the checkings?
- value checking: Select Case
- type checking: Select TypeOf
- object equality checking: Select Object

There are many aspects and I want to give a good answer.
I'm thinking about it...
some days...