Thanks for the comments!
Client registration does a couple things. One part is the security gained by the client being able to authenticate, the other is providing metadata about the client such as the application name and logo.
IndieAuth skips the need for client registration for metadata purposes by using URLs as client IDs and having the metadata published at that URL. PKCE is still a necessary step to provide an alternative to the authentication part of client registration. In fact, the latest version of the IndieAuth spec recommends that clients also use PKCE! There isn’t a need for a v2 spec because PKCE can be added to existing OAuth systems in a backwards compatible way, which was one of the design goals of PKCE.
Interestingly, ActivityPub doesn’t actually need Webfinger, and in fact one of the principles of the W3C SocialCG (where ActivityPub was developed) was to take a “follow-your-nose” approach to spec design, which specifically avoids approaches like Webfinger with hardcoded URLs. Personally I’d love to see ActivityPub drop Webfinger in favor of discovery methods that don’t rely on hardcoded URLs, but that’s a different discussion.
Creating an maintaining a spec is not a small undertaking, I wouldn’t recommend creating something new if at all possible. Over the years, we’ve been trying to make IndieAuth closer and closer to plain OAuth 2 so that it has less functionality that is different, just to make it easier to understand and maintain.
I’m pretty sure it would be possible for a developer to pick up IndieAuth and use it with ActivityPub clients and servers today exactly as written!