This might be a bit more complicated one, so brace yourselves.
In my company we have a medium-large codebase, with 85% C#, 10% Python and the rest is C++ interop used for some C# projects.
Up until now, everything was developed in a single monorepo, single solution kind of way (~12 years of development) using subversion.
We have about 230 projects in our solution of which ~15 are applications that are distributed to our customers. Most of the rest are large, badly intertwined libraries that are basically all over the place.

As you probably can imagine by now, the whole thing was/is a whole mess, resulting in many pain points: Build times are very large, independent development nearly impossible, every month it gets worse, not scalable for another 10 years.

So our idea was to finally move over to Git and leverage this migration to split our mono-solution into more adequate smaller solutions that are better maintainable and are easier to develop on.

In the first step we moved all applications into their separate git repo, allowing us to get familiar with this migration process, meanwhile having a fair amount of work for every application. Most of this part is done and was fairly easy, since we have several applications that are only loosely coupled to the rest of the solution.

We are now left with ~180 libraries that are shared across many applications. After 2 days of team meetings, discussing clusters that make sense thematically we started to migrate the smaller clusters first. All this is obviously happening during normal development time, resulting in split universes that we are working in:

• Applications and some libraries that are already migrated to Git are using NuGet packages that are generated from the remaining SVN libraries. These .csproj are using PackageReferences (libs not in their specific repo) and ProjectReferences (libs in their specific repo).
• Remaining libs in SVN are mostly using ProjectReferences and only in some rare cases PackageReferences to libs that have already moved to Git.

As we started to migrate the larger git repos, the ones that contain the most important 40-60 libraries, we started to run into a lot of conflicts:

An assembly with the same simple name 'XXX, Version=2.0.0.1, Culture=neutral, PublicKeyToken=null has already been imported.

Try removing one of the references or sign them to enable side-by-side. C: . . . XXX.dll

This happens, as we discovered, because we are combining Package and Project References.
Of course we could simply PackageReference everything, but this would make development and debugging a lot harder, because we always have to push a new NuGet release before being able to use changes from one library in another, even if both are in the same git repo (the main point of creating clusters).

Maybe we are overlooking something, but PackageReferencing everything seems to be the only main solution to our problem. Did somebody go through a similar scenario and could give some advice?