The only caching mechanism I use is Ccache, and it is able to cache the intermediate object files perfectly well.
I was definitely referring to a distributed caching solution which would hash TU contents across developers. Unity builds tend to break since changing file structure (adding, removing, moving files) will result in different TUs being globbed. There are “solutions” to this of course, which result in additional complexity in how the Unity TUs are assembled. I agree that if there is no interest in distributed caching mechanisms, this drawback is less pronounced.
Maybe I’m missing something and it is indeed a bit sad, but afaik unity builds are the only solution that actually remove the redundancy in the parsing and code generation stage.
Arguably, I think the best thing to do is to have as little code in a header as possible. You mentioned type erasure early on which I think is the best approach. Arguably, libraries like the STL would be much much faster to compile if they performed type erasure in the template, before dropping down to a forward declared type-erased implementation, housed in exactly one translation unit.
I’m curious, did the game engines you worked on just enable unity builds and fixed name collisions when they came up, or did they actually structure the code to work well with unity builds?
Name collisions were indeed fixed as they arose, although there were some soft conventions in an attempt to try and avoid this sort of thing. The flavor of the solution was different in each engine though, although it was particularly tricky in some engines due to the presence of a custom preprocessor as well (notably, Unreal Engine’s custom preprocessor doesn’t support namespaces, and they are full adaptive-unity build).
In any case, if it’s working for you, it’s working for you! I have been personally afflicted by years of pain due to Unity builds, but I understood fully that my experience is in no way universal, and the full extent of that experience doesn’t apply in every situation. 