"Project" is a super overloaded term. I completely understand that the community is going to call things what they want to call things and fighting that is futile. But I want to at least make sure that everybody on this list are on the same page regarding how the Eclipse Development Process sees projects and everything that follows from that.
"Project" has specific meaning in the Eclipse Development Process and "Specification Project" has specific meaning in the Eclipse Foundation Specification Process (which is based on the definition of "Project" in the EDP).
A Project is the main operational unit for open source development at the Eclipse Foundation. A Project has a single team of committers, one or more project leads, and a collection of shared resources on which every member of the committer team has uniform access.
Git repositories are one of the resources allocated to a project team. Every member of the project team (i.e., every committer on a project) has the same write access on all project resources as every other member of the team. In practical terms, we set up and manage a single GitHub Team for each Eclipse Project committer team and assign all GitHub repositories associated with the Eclipse Project to that GitHub Team. We do not configure teams at the repository level.
If a hypothetical single Eclipse Project (or Specification Project) has "*-api" and "*-spec" GitHub repositories, then every committer on that Eclipse Project will be able to push to and accept pull requests for both of those repositories.
So... by keeping the repositories separate, it would be easier to manage (by convention within the team) which team members should or should not be working in a particular repository. The separation would not prevent a committer from dabbling where they should not, but the clear separation would at least help them understand where the lines are drawn (and maybe make it easier for other committers to notice when they cross the line). FWIW, a lot of Eclipse projects get along very well with this sort of practice.
Another consideration... we might want to keep the spec and API separate to make it easier to maybe split an existing single project into separate Specification and API projects at some point later. Any such split, however, is not on our current plan, and I very strongly recommend that we don't try to add this to the critical path for Jararta EE 8.
Note that we can split repositories and projects at a later date if circumstances dictate that doing so makes sense.
Wayne