My 2 most painful points today that would be easier to alleviate by the fact of not having to do with .NET5/6/Mono/CoreCLR/etc have to do with project generation.
1. Inability to use Nuget packages
The fact of not being able to do it leads to having to bring the whole chain of dependencies of a nuget package manually (dll one by one) with the loss of time that it supposes initially and in the consequent updates.
It has led for years to “fight” conflicts of different versions of asset store asset assemblies or even official Unity packages. Examples:
Another problem that I’ve been fighting for quite a long time and I managed to solve partly thanks to @HaraldNielsen : Editor assembly loading issues - "unloading broken assembly", "could not load signature"
Luckily since the emergence of UPM projects like @xoofx (GitHub - xoofx/UnityNuGet: Provides a service to install NuGet packages into a Unity project via the Unity Package Manager) have emerged, to which I have contributed in several PRs and it helps quite a lot at least to be able to add nuget dependencies “in the world” of UPM.
I do not understand how in the era in which Microsoft embraces open source and cross platform tools, Unity does not take advantage of them and alwaays tries to reinvent the wheel with the expense of time (“NPM → UPM fork” instead of using Nuget, Mono fork very far from the official one with the complexity of updating it, …) and resources when it could be focused on functionalities more typical of an engine like Unity.
Since Unity left aside the other two languages (UnityScript and Boo) I don’t understand why it doesn’t use official .NET tools.
2. Replace asmdef files with sdk style csproj files
I see that this is something that is going to be worked on and I am very happy because it is something that solves the first problem and solves many others.
Since the sdk style format was created it makes it very easy to edit the csproj files by hand so it would not be necessary initially to have a special inspector in the editor unless you need properties that you want to migrate from Unity’s own asmdef.
A problem that we encounter is the same as @Issun and many others and is the fact of being able to reference external projects to Unity (pure C#) without binaries (source code directly) as is the very common case of our communication protocols between a backend and Unity: Rest APIs with NSwag, shared data models, utility libraries, etc …
It would also solve in part the continuous reloads with the Visual Studio blocking dialog that makes you open a new instance of VS. With SDK style reloads in many cases happen in the background without blocking interaction.