Heya! I just wanted to follow up with this to make sure everyone knew what my solution became.
Ben, I tried your solution, but I had trouble getting the classpath configured properly, and additionally, the declared dependency of my plugin was bleeding into conflicts coming from other plugins. E.g., I couldn’t use a parent-first strategy because some of the crashes were coming from actually calling tasks on other plugins when I conflicted with their classes.
Ultimately, I went with a solution that dynamically invokes the main from a fat jar bundled inside my plugin. This has the effect of the gradle plugin classpath never having my artifact dependencies on the classpath AND my dynamically invoked class only uses its local classloader, thereby never interacting with the gradle one.
This solved my problem, but felt a bit outside the box. It does feel like something that probably could be automated outside of my plugin without changes to the gradle DSL. OTOH, I like having access to class definitions of other plugins’, as that allows me to react to, for example, the android-gradle plugin’s domain objects.