Sometimes it makes sense to have different bug trackers for each sub-product, but also one for support, and one for your infrastructure issues, and a locked-down one for security tickets, and maybe another for packaging issues - any of which may not have associated source repos. Whatver organizational model meets your project's needs best, you have the flexibility to apply it. And people often do! A lot of the projects on sr.ht, given this flexibility, haven't recreated the same model as GitHub shoehorns you into.

It goes beyond bug trackers, too. One other detail is that different projects can share resources with one another. I use one mailing list to slurp up all patches for my smaller side projects into one place, for example.

Gotcha, that makes sense. Thanks!

I think this was just an example, really, but I know some projects have an external bug tracking tool to document customer-reported issues, and closed, employee only ones to discuss the issue internally.

So you can have a separate one for "internal" and "external" customers perhaps?