In most cases, you should only have one project per product. The desire to split a single product into multiple projects is usually a sign that inter-team collaboration and iterative integration have become a central bottleneck for your process. I provide additional analysis and recommendations below.
One Product ➡️ One Project ➡️ One Integrated Increment
When should a multi-team project be split to run as separate projects?
As a rule of thumb, each project should run from a single Product Backlog. In each of your examples, you may have multiple teams, but each team is still fundamentally working on the same product.
Even if you’re split into feature or component teams, you’re all still developing the same product, and should all be working from the same top-level Product Backlog. You want to keep this central coherence, as it’s a core element of cross-team collaboration.
Your actual challenge seems to be integration. When working with multiple teams, or when work is split along feature or component lines, the central challenge is to ensure that the loosely-coupled work that each team is working on during the iteration still comes back together to represent a potentially-shippable increment at the end of each iteration. That potentially-shippabke increment is the central coherence that aligns your teams and keeps the product development on track.
Scaled frameworks like Nexus or SAFe each approach this challenge differently, but they also share some commonalities. Continuous integration is a great practice if you can manage it, but that’s not always practical at significant scale. However, frameworks like Nexus address the need for cross-team integration by having a dedicated team whose responsibility is to ensure that all work from the various teams can be successfully integrated and delivered as a unit at the end of each iteration. Whatever framework you follow, ensure your teams are collaborating sufficiently to allow for continuous or per-iteration integration, so that the product is always in a potentially releasable state at each major inspect-and-adapt inflection point.
The details may vary by framework or by organization. However, unless you are actually attempting to deliver multiple products, you should ensure that your teams maintain a central coherence and treat iterative integration as a first-class element of the multi-team process.