@MrJohnHimself - another option is to make your ALM structure component centric as opposed to Solution centric. This means adopting Microsoft's recommendation of using "Segmented Solutions" in your ALM.
If you have a simple app with a couple of tables and a few components, and you can be virtually certain those components will not be depended on by other Solutions, then using a Solution is the recommended option. In addition, if you have an app which uses Flows and those Flows are only associated to that app, then packaging those components into single Solutions is fine as well.
Where trouble can begin, and as you have noticed, is when you have up to 50 Solutions which share the same components in, as you put it, "a tree-structure depending on each other".
For example, suppose Solution A includes a specific component, such a Table, a Flow and a Canvas App. Developer A is making updates to the Entity views and Flows, while Developer B is currently making updates to the Canvas App. If we included all components into a single Solution, we cannot import to Production yet because although the Canvas App is ready to deploy, the Entity View and/or Flow is not.
One option to address this, and one which I personally use, is to adopt the segmented solutions approach for ALM.
https://learn.microsoft.com/en-us/power-platform/alm/segmented-solutions-alm
By segmenting the Solution, you only include components that are ready for distribution as an update into the Production Environment. The fundamental purpose of this setup is to avoid cross dependency risks when managing multiple Managed Solutions in the same environment, because as you're aware, cross dependency errors are a nightmare to resolve.
Another problem segmented Solutions can potentially avoid is a scenario where several Solutions contain the same component. For example, Solution A includes a specific component, such as a Security Role. Later, you also have Solution B which also includes the same Security role as a required component. Later, you remove the Security Role from Solution B but receive an “import failed due to missing dependencies” error because Solution A depends on it.
Note however that for this solution to properly work, you will need to:
1. Import your Unmanaged Solutions to your Developer Plan Environment as a holding area and take zip backups
2. Completely reset your Dev, Test and Prod environments.
3. Take the Unmanaged Solutions and start splitting out the components into separate Solutions
4. Import the Segmented Solutions back into your Dev, Test and Prod environments to end up with something like this:

Given your doing automated deployments via Pipeline, I should caveat that managing individual components in this way via a segmented Solution creates more work, but it is a very workable option for you.