This only covers a small part of the problem. Things that should be private and requite separate yesting are atill required to be more visible than they are supposed to.

I have the opinion that is the job of functional tests anyway.

Unit tests should only exercise public interfaces, with internals and private parts being tested as side effect of calling them.

This simply cannot work in many cases. It is quite unrealistic to test complex logic that is hidden behind a narrow interface completely. You are hit with the full combinatorial complexity of what is behind that interface, even if might consist of independent parts internally. If you can test these parts independently, the number of required tests is a fraction of what a black box approach requires.

Another situation is checking numerical code for correctness and accuracy. There it is extremely advantageous to have testable small functions that map to individual mathematical expressions. But these are again implementation details that need to be hidden behind interfaces.

That leads to program for unit tests, exposing parts that shouldn't be visible in first place.

Your numerical code example can be achieved with an Assembly of internal functions/methods, exposed only to the implementation and unit tests.

Of course, this is easy to do in a greenfield project from the start, not so easy on legacy code.

Your first statement is exactly what I've arrived at. It's just not avoidable in general.

I have to clarify that I'm not fixated on C#. Sure, you could create a helper assembly in .NET that is a mess of essentially of disembodied functions for computing every slightly more complex function that happens to be in your program. But this breaks OOD.

In C/C++ you can't do quite the same. The best you could do there is break OOD and try to hide these global functions by using private headers (which are ugly in their own ways).

There is also composibility: ie make public components and compose them in public, use private as little as possible.

True, just that when you make the pieces too small you can get into component spaghetti as well.

Yup. And you can completely ruin performance, if that is something you need (I do in some of my code). Abstractions in the wrong places can hurt.