Not sure, but isn’t unity in this case covering your need for some tools, like rendering, assets management and so on, but maybe not all - i.e deferring to them the physic. Or so would I say assume ?
I heard from someone who actually works in the industry (as engine developer) that companies usually don't use Unity out-of-the-box and write their own tools and extensions (e.g. memory management) and change parts of the engine as the needs vary greatly depending on the game they are making. Not sure how common that really is though.
You may be referring to Unreal in this instance. Unreal is open source* but you pay to license the engine, so you can make core changes I.e. memory management or tweak underlying net code. Unity is closed source and so you can only really extend very core parts of the engine.
FWIW my experience in gaming has been that Unity is exceptionally powerful and allows game developers to create games that would otherwise require an entirely separate dev team to support the engine. When I first learned game dev, the code sections were almost entirely devoted to interacting with the underlying graphics libraries (OpenGL or DirectX) and hardly any to creating powerful features in a game. Now, using something like Unreal or Unity is akin to using a web framework like Ruby on Rails or Laravel.
I think you might mean that unreal is "source available" which doesn't confer any of the rights of open source, but does allow you to view and modify the source code subject to a commercial license (which might be free for personal, small scale use. I don't know unreal's pricing structure).
Unreal is not open source (cf. the Open Source Definition: https://opensource.org/osd/). It's just that the licencee is allowed to view and modify the source code within the limits of the licence.
BTW, unity does offer a full source of the engine to companies that are willing to pay enough for it. So you can effectively modify it as much as unreal.
Although, I don't even know if the KSP2 studio is big enough to afford it, let alone if they are actually doing it
My limited experience with Unity was that, if you are planning to do something the Unity way, its very easy to bootstrap and start just coding cool features. Which is why theres a proliferation of Unity store assets + cheap gameplay on steam.
But if you want to do something a bit more complex, like modifying 3d objects in flight based on unit interaction, not only are you fighting an uphill battle, but the documentation is all out of date and mostly wrong. Because Unity isnt just an engine, its a set of default addons to that engine, and each of those addons was written to be just generic enough, but mostly just enable people to start making FPS and RTS games really quick. If you want to step outside that paradigm you are basically just engine coding again.
Plenty of companies have source access to Unity and write their own custom portions of it. It's just not accessible at the hobbyist or indie budget level. It's one of those "call us for pricing" situations.
Common patterns from non-indies using Unity is something like that: write your game with the idea that Unity handles the rendering and media stuff, everything else you write/manage yourself with a proper C# codebase.
> write their own tools and extensions (e.g. memory management)
I've been using Unity since 2009, and have been a lead developer and CTO in several different companies. I have never heard anyone writing their own memory management for Unity. May be you're talking about object pooling?
It's kinda what ECS is, depending on how loose you want to get with the term memory management. And studios have implemented their own ECS in Unity long before Unity's official ECS framework.