Duncan talks about upgrading a project from VB.NET 2003 to 2005, and the default change in the rule for accessing Shared members from an instance variable. An important thing to note is that this is a compiler option ... you can turn the rule off, set it to warn, or set it to throw a compiler error.
As to the change itself, I personally don't like it. Sure using the type is usually preferable for readability, but is it for discoverability ? Let's say I have :
Dim s As String
s.
at this point intellisense should list all the members for me. In 2002 and 2003 it does exactly that, but in 2005 it no longer does. So how exactly do I know that Concat is there, or Copy is there etc, etc ? I can look in object browser or try a hit and miss approach of typing String. and s. to see what each one lists. so discoverability is now hampered for a what really is just a pedantic rule. The rule itself can be turned off, but intellisense is NOT restored.
So although the goal may have been a good one, the way this has been implemented is very bad.
Instead, as I suggested some time ago, a better approach would have been to list shared members in intellisense (or at least make that an option) with the typical overlay of S for shared members. That way shared members could be easily detected ... discoverability is preserved (even enhanced)
And of course if it was set not to allow shared members from instance types, then the editor would replace the instance variable with the type when you select the shared member.
So it's not as much a matter of the change, but more the way this change has been implemented. Removing Shared members from intellisense for instance variables lessens discoverability.