[SUGGESTION] C# is a second class citizen in vscode (.sln files are workspaces NOT folders in .NET)

Describe the feature you'd like

.sln files are workspaces in .NET NOT folders

• No way to open .sln files without opening folders first (feels like C# is now a second class citizen)
• No NuGet management without using command line?
• No way to manage .csprojs in solution
• No way to unload .csprojs in solution
• No way to manage solution level build configs
• OmniSharp doesn't load .csproj or .sln build configs for debuging
• Building an IDE around HTLM/JS/TS was a huge mistake.
• Making users sign into MS accounts is a huge mistake.
• Most serious cross-platform dev is now going to be using Rider as VScode is a massive IDE regression from MonoDevelop.
• Long run this could actually do harm to C# as a language because it now feels like a alien to the IDE and a second class citizen.

Alternatives considered

• Get rid of the hack that is OmniSharp and use standards around MSBuild
• Make a new .sln alternative thats human readable & foundational to the Roslyn compiler
• vscode needs to conceptualize workspaces around what extensions feed it not what folder is open
• Make a new IDE built on C# & AvaloniaUI that actually functions like a normal IDE

In short vscode is hacky, confusing and a poor experience to what was & you need a elegant system for dealing with .csproj files that don't live within a folders scope.
The .sln file has been a core part of .NET dev for 20 years. Yet ppl on the vscode team seem to pretend this doesn't matter.
vscode is now trying to be an IDE when it is so fundamentally flawed for the task when it comes to complex workspace scoping issues, it makes zero sense at a fundamental level.

In fact this scoping issue is such a big problem it now means any lang that supports scoping files outside a folder now have to deal with these kinds of IDE disparities.

Environment Information

Win, Mac & Lin

Start by separating the .sln and .csproj workspace concerns from the OmniSharp, MSBuild, NuGet, debugging, and account-sign-in concerns named in the issue. The report does not identify files, tests, or a single acceptance criterion, so it needs a narrower scope before implementation can begin.