I actually do think we disagree somewhat — and that’s totally fine, it’s a good convo.
I’m not against changing internal systems to make them easier to test, as long as it aligns with simplifying the overall design.
That said, I’m all for functional cores, values as boundaries, and orchestrating shells — but I also accept the case for internal mocking. Gary Bernhardt gets away with “not testing the shell,” but I’ve had imperative orchestrators with enough logic to warrant their own tests. In those cases, I have seen value in mocking internal systems to focus on how the orchestrator handles edge cases — without spinning up and configuring full subsystem-domains.
To me, the foundation of testing is putting systems “under the microscope,” without being overwhelmed by unrelated concerns. This touches on the timeless “classist vs. mockist” debates, which ultimately come down to context: complexity, team dynamics, and other tradeoffs. The tension between those perspectives often pushes better design — which is why it’s such a classic topic.
To be clear, I’m not advocating for mocks everywhere (though I’ve probably sinned in that direction before), but I do see mocks as a valid tool in the toolbox — worth considering as part of the tradeoffs (even if just temporarily, until we land on a simpler, more robust design).
The testing space is wide. It has to be, to fit all of us 
