Im not Moulberry so I can't talk on his behalf but a way I can see this that would work best is using a service loader or some property to override the abstractions class to get from the class loader

I was thinking about using a property for that, as it's much simpler to do than a service loader, but both are 100% fine.

I was also thinking of contributing on how some internals works to make the loading the extension work in the same way MixinExtras/MixinSquared work, so using a custom MixinPlugin would not necessary if the bootstrap init method was called.

If I my contributions are wanted, I'll do separate PRs for both changes.

Property seems fine. It could potentially cause issues if a new constraint annotation needs to be added which the custom environment doesn't support. I suppose in that case it can just default to always passing. PR is welcome.

Don't worry about adding new stuff, it's up to the consumer of the Abstraction API to adapt to new updates.

I made both my PRs:

• Allow custom Abstraction implementation. #9
• Rework how MixinConstraints disable mixins. #10

They should be able to be merged in any order.

I commented on #10 with an issue. There's no issues with #9 as far as I can see, but I'll wait to see if there's any response to 10 before merging 9 and making a release.