You completely missed the problem that submodules are actually supposed to solve though. Using them for either of those cases would almost definitely be the wrong choice.
What they're really for, is vendoring someone else's code into yours. They're still not great even at that, but sometimes they're the best option.
Interesting. When you say that's the problem they're intended to solve, do you have a link to that as their intended use case.
IE is that "a" usecase or "the" usecase? I've never seen submodules used for that, only for internal dep management, so if there's content about "what they're really for," I'd love to read more.
When I worked in games we did exactly this but with perforce. All of our libraries were in a vendor tree and all in source. We slapped our own build over the top of them and checked in the build artifacts (perforce). If we needed an update, we updated their code and maybe our build script.
It'd be nice to use submodules for this but I gave up years ago.
The other big use is where you have your own libraries and you'd like to be able to share them across projects. My friend does game jams and has his own simple engine, he versions the engine and adds abilities and uses it across game projects.
Vendoring usually implies some kind of snapshot-copying of third-party code. A repo you depend on by value. That's actually solved by subtrees. If you buy that metaphor, then submodules, in contrast, express a dependency by reference.
tl;dr anyone vendoring with submodules is prolly doing it wrong
What they're really for, is vendoring someone else's code into yours. They're still not great even at that, but sometimes they're the best option.