The main thing that’s putting me off is that, if we add include_guard and remove it at some point in the future (because we discover some unintended consequence of the include guard), the removal will be a breaking change. However, if we leave it out, we can add it at any point without breaking peoples’ projects.
Hiding the JUCE dependency sounds nice in theory, but that’s only going to work if util builds as a shared library with hidden symbol visibility, so that none of the contained JUCE symbols are visible to main. I think in practice, if util is a static library you need to know that it uses JUCE because otherwise you might end up (for example) building juce_core into both util and main. On some platforms this would result in “duplicate symbol” errors at link time, but on other platforms the duplicates will get silently discarded and the linker will just choose one set of symbols to use. If you’re lucky, this will result in weird runtime crashes when types with unexpected layouts are passed to some function (imagine util was built with JUCE_STRING_UTF_TYPE=8 but main was built with JUCE_STRING_UTF_TYPE=32… strings are going to end up broken in either util or main depending on which symbols the linker decides to keep). If you’re unlucky, everything will appear to work for a while, but then break when util changes to a different JUCE version than main.
At the moment this kind of project organisation just feels a bit too error-prone to explicitly endorse with an include_guard.