Support Multiple Logical "Views" of the RolsynDom tree

[KathleenDollard]

I have collapsed as much as possible into a single logical tree. However, there are several scenarios where the language provides a nested level, and you generally don't care. But sometimes you care. OK, there's the challenge:

• Namespaces (namespace Foo.Bar or namespace Foo { namespace Bar. Some work is already done on this and shows the overall approach I plan on this problem. There are two sets of methods. I just need to zero in on very consistent naming so you can get muscle memory on what you generally want.
• With in VB
• random braces marking blocks in C#
• checked blocks in C#
• locked blocks in C# (better idea DON'T USE THEM)
• volatile blocks in C# (bettter idea DON'T USE THEM (see Jeffrey Richter's work for discussion of both)
• using statements in C#
  (I feel like I'm forgetting some, I've been meditating on this for months)

The last is questionable, stepping toward where you always want blocks - conditionals and loops.

There is also one scenario which appears in line, while you very often want it to be a block

• await in C# and VB

I can't just add optional methods for each option as the number of methods due to the dot product would be enormous.

Now that you understand the problem, here are my tentative plans (please comment, I've been working on this problem for months)

• Namespace - 2 methods, collapsed, not collapsed, and more importantly, you can get to root classes ignoring whether there are any namespaces
• With in VB -always ignore
• random braces in C# - always ignore
• checked in C# - always ignore

Always ignore. Treat these as directives (assuming I can sufficiently resolve in VB. Note that directives are not trivia in RoslynDom, so these will be available and the more I look at checked, the more I wish it was a C# directive (because it doesn't affect called code).

• locked blocks in C# (better idea DON'T USE THEM) - always bracket

• volatile blocks in C# (bettter idea DON'T USE THEM) - always bracket

  I want these painful - see Jeffrey Richter's work for discussion of why not to use them. I'm working from memory so I'll check on this.

• using statements in C# - I don't know.

Three different days, three different answers. Hoping for an aha moment!

• await in C# and VB

Alternate methods. I don't know which StatementsAll will use, but I expect an alternate nested form. I wish I'd been smart enough about.

This problem being correctly resolved is why await isn't yet supported. I'd rather make you wait than muck this one up because it is so important.