The current way means that Sponge’s version of SpongeAPI will always lag behind, that there is a lot of duplication between the two repositories for build tooling, and that it’s impossible to submit a pull request that contains both an API change and an implementation of said API change.
IMO, the Sponge implementation should be a subproject (or sibling) of SpongeAPI, so that plugins (or forks/reimplementations) can still pull in SpongeAPI as a source dependency if needed without touching SpongeImpl, while making it obvious to keep everything in sync.
Like bukkit, you wouldn’t have bukkit and CraftBukkit in the same repos. If you want an API change and a implementation change just make two pull requests. And they will not lag behind, just update both…
I know that they are separate in that the dependency should be one-way, but that doesn’t mean having to version them separately.
But they are intrinsically linked together. Updating SpongeAPI but not Sponge will mean that Sponge doesn’t implement the interfaces fully (breaking the build). Updating interfaces in Sponge but not SpongeAPI either means it doesn’t implement the interfaces fully anymore (breaking the build) or is effectively useless, since plugins can’t access it anyway.
Look for yourself, if you try building from Sponge right now you’re using a SpongeAPI version from 4 days ago.
To be honest that could mean less at this moment in time. At this stage in the project the team is mostly planning and laying out the framework. I would expect that they are focusing on the framework more than the versions at this time, since the versions are not even for public release.