No. As you say, the moment you have a real out-of-process dependency, you no longer have a unit test, but an "integration-with-external world" test.
The heart of the argument is to not mock out internal (in-process) business logic. Instead:
a) do not use mocks (e.g. leveraging Moq); use fakes (aka "simulators"), i.e. proper classes having in-memory implementations of the out-of-process dependencies and crucially
b) replace only out-of-process dependencies, which usually are flaky/nondeterministic. Never replace internal business logic.
If you feel you need to replace internal business logic, you are not following the functional core architectural pattern. After you refactor to functional core you will no longer need to replace any dependencies in your unit test, as there won't be any - you will just call your tested pure method and make assertions on the returned value.
Special case here is testing "top-level/controller" logic. Here you need to use the in-memory fakes, but there will be only few, reused across all tests, and such test will be an "end-to-end internal-business-logic integration test", but still it will have all the properties of a unit test - it will be fast, deterministic, and you will be able to run it as part of a unit test suite out-of-the-box, with no environment setup necessary.
Further reading: https://enterprisecraftsmanship.com/posts/when-to-mock/
> If you want to change code you will always measure the effect it will have on the code and tests are incidental, not the primary concern
Exactly. Mocks are very brittle and break all the time, causing unnecessary rework. If you instead rely on a small set of fakes of out-of-process dependencies, you will drastically reduce test suite rework and improve signal-to-noise ratio.
> Using a real dependency, I would be left in the unfortunate situation of depending on knowledge of the internals of that dependency.
And what happens if the real dependency changes behavior, but you forget to update your mock? You will have a test that will be running against a mock that simulates obsolete behavior, no longer present in production. In worst case scenario the test will be green/passing, while there is a bug in production. Will you remember to always comb over your entire test suite and review all mocks to faithfully simulate actual production behavior?
> It may not allow me to execute specific paths via pure configuration at all.
If you write fakes, you will have full control over how to configure them.