As much as I want to agree with you, I get it:

- To avoid polling, you want to be able to register a webhook to be notified when pushes happen. You're going to need Git-servicet-specific parsing of the webhook payload, and you probably want to be able to speak a Git-host-specific API to automatically register that webhook to make it easy for users. (Falling back to polling would be good, but few do.)

- If you're a paid product, you definitely need to support private repos. You probably want to be able to speak a Git-service-specific API to set up the credentials to be able to do that `clone`; in GitHub parlance use the API to create a "deploy key", rather than requiring users to manually mint an SSH key, set up a bot account on the Git-service, add the SSH key to that account, and upload the SSH key to the CI-service. (Falling back to being able to provide a raw Git URL and credentials would be good, but few do.)

- To avoid confusing user-account permission mismatches, you probably want to piggy-back on the Git-service's user system; supporting "sign-on with X" and using the Git-service's "is admin of this Git repo" for allowing access to your the CI-service's admin interface for that repo.

- You want to be able to post statuses back to the Git-host. This takes a Git-service-specific API. (Falling back to letting the user provide their own script for posting statuses would be good, but few do.)

FWIW the first two are solved by git without any service.

Git can set up a post receive hook, which could do the triggering.

SSH key auth is a thing as part of Git+SSH.

Sure I couldn't set this with e.g. GitLab without them supporting GitLab, but if I'm self-hosting a git service, this seems like a fine solution.

I would guess it falls into the "what assumptions does the runner make?" followed closely by "there is no standard for what env-var contains: the current branch, the commit sha, the commit message, the current pipeline identifier, ..." and a bazillion other bits of contextual information

Made worse by: ok, fine, you magically have `eval $(git set-env-from-commit HEAD)`, now how do you report those run results back to the upstream UI, since there is for sure no standard for that

I doubt there was a problem cloning GitLab-hosted repos on CircleCI before this announcement. But there are plenty of non-Git things that these hosts do; pull requests, status checks, etc. I am guessing that "support for ..." entails all of those extras.

Because the integration is entirely built on webhooks and each Git hosting provider has their own.

You would be surprised at how little of the code in a CI product, like CircleCI, deals with git. On the other hand, there is a lot of code required to integrate with the VCS - authn, authz, webhooks, commit-status, etc.