It seems to me that the logical conclusion for captcha is to connect it indirectly to electronic id. This could be done in a privacy respecting way.
You could get some token from the website. It could include encrypted service name and policies, like rate limit, that the authority should enforce. The client passes the token to the eId authority. The authority signs it and adds timestamp, but no user info. Client gives token to the service. Something like that. This is a bad top of mind example.
I think we'll need to rely a lot more on eID in the future. I think it can be done in a good way but then it needs to be thought through before it gets adopted. And we have to be able to trust the eId institutes.
But it's the same problem all over again, spammers would get an id, auth, then spam.
Anti spams are about detecting whether activities are spam.
Binding an identity, is the naive mechanism that makes us think spam wouldn't happen. All it does is say ok we know it's pug35372 that teared the linens apart.
We can put all measures to authenticate users, won't makes them not potentially bots running havoc right after a manual authentication.
There are even farms, manually created accounts by gig seekers who would fill forms, email and phone number verification for less than a dollar.
As I mentioned the exchanged token could include a number of policies, like rate limits. But I expect there could be more sophisticated policies as well.
The service could send ban or lockout requests to the eId authority so that a misbehaving real life user could be locked out from the service even though the service doesn't know who they are (irl).
I would guess it could even be designed so that the authority doesn't know which services a given user has been banned from either. And all the service would need to know is "This user has violated policy X at <timestamp>".
2FA and logged-in experience is sort of a proxy for eID. I suspect that's why so many companies require that you log in with something that knows your identity (log in with google), or ask you for your phone number to confirm your account
You could get some token from the website. It could include encrypted service name and policies, like rate limit, that the authority should enforce. The client passes the token to the eId authority. The authority signs it and adds timestamp, but no user info. Client gives token to the service. Something like that. This is a bad top of mind example.
I think we'll need to rely a lot more on eID in the future. I think it can be done in a good way but then it needs to be thought through before it gets adopted. And we have to be able to trust the eId institutes.