Design principles like SoC in the context of a common library

I am currently working on a couple of .NET web applications (MVC) that are functionally independent. We've kept our projects for each encapsulated following separation of concerns. So we've ended up with projects like:

App.DataAccess

App.Services

App.WebApi

App.Domain etc

There is a chunk of code that is effectively shareable between the two components and these have been separated out into their own projects.

Common/Core.DataAccess

Common/Core.Services

Common/Core.Domain

Common/Core.WebApi etc

The situation we are working on fixing now is that this 'Common code' is basically duplicated to both applications and we're using process as a band-aid to keep them in sync between the two applications.

After some research, my proposal so far has been:

1) Create a private nuget feed (hosted on our own server)

2) Give the common code its own solution and push it out to this feed.

3) Both applications now install this common code as a nuget package.

Generally speaking, everyone is happy with this approach. The disagreement comes from structuring this new solution.

Common currently consists of 9 projects, with some projects being as small as a single class. The largest project is <25 files big. I feel we should consolidate everything into a single project and use folders and namespaces to encapsulate.

The concern the team has, is that separation of concerns would be violated as our web project would reference this nuget package and have access to some Data Access components.

Is there a generally accepted pattern to be followed here or is the best solution to keep 9 projects and 9 nuget packages to keep SoC satisfied?

Appreciate any guidance here!

~Saagar