I drafted a very long response to this issue for the previous thread. I'll see if I can still find it and post it as a new thread.
But basically, you can start with this from semver.org:
In systems with many dependencies, releasing new package versions can quickly become a nightmare. If the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade a package without having to release new versions of every dependent package). If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity (assuming compatibility with more future versions than is reasonable). Dependency hell is where you are when version lock and/or version promiscuity prevent you from easily and safely moving your project forward.
There are times when you want a kind of version lock - when you have the power to, as it says, release new version of every dependent package. But generally you don't have that power.
Now, recently we have introduced the package access level, and IMO that changes the game significantly. Now I think we actually have a clearer idea about what a "package" is - it is a unit of distribution, and a unit of versioned code. If your "internal packages" are versioned together (you want version lock), they should perhaps be considered modules in the same logical package.
We might need better tools for arranging different folders of code in to a single logical package as part of constructing your Xcode workspace or whatever (maybe your whole workspace is one logical package). Perhaps that is a path forward.