When I do dotnet sln add {myProject.csproj} for a .NET Core/Standard project, it adds it as project type (I think) {FAE04EC0-301F-11D3-BF4B-00C04F79EFBC} instead of .NET Core's {9A19103F-16F7-4668-BE54-9A1E7A4F7556}.
Hence, when I open the solution in Visual Studio, it complains and "upgrades" the csproj to a .NET Framework csproj, not a .NET Core one. I can manually edit the sln but it's a chore.
Am I doing something wrong? Are there arguments I'm missing?
The CLI is actually doing the right thing here, this is a VS/Project System bug.
The CLI calls into msbuild to get the default project type GUID to use. MSBuild sets the $(DefaultProjectTypeGuid) for C# and VB projects to the "classic" one to allow the CLI to add both "classic" and "SDK-style" projects to a solution.
The classic GUID (FAE04EC0…) is then triggering a selection logic that looks if TargetFramework or TargetFrameworks is set in the project to determine if the "new" or "classic" project systems will be used. The idea is that at some point only the new project system will be used and the classic project system may no longer be part of VS in some future update (this is the tone of a lot of comments on GitHub).
According to the logged GitHub issue, the bug is that when the new project system is elected, the solution is updated to the "new" GUID which VS/the solution shouldn't see.