are there any consequences of changing a group:artifact of a plugin if you don't change the plugin id? (presuming most people are using the plugin id... I suppose would be the most obvious)

I guess not, except as you mentioned if people depend on it in their convention plugins directly, or have some configuration regarding it like telling the dependency analysis gradle plugin that it is ok to use things from there transitively when depending on the marker artifact, or if they follow the legacy way to add the plugin to the buildscript dependencies, or have some dependency constraints regarding it, or have some licence check configuration regarding it, .... So all in all, I personally would avoid it unless there are really compelling reasons to do so and if you do, well, some things will most probably break but probably nothing that is not relatively easily fixable. 🤷‍♂️

Makes me wonder is there a way to publish both but put a deprecation in the gradle meta data so those on older group:artifact would be warned for a release cycle or two?

right, I've noticed maven central has a way to do redirects but not certain that can be in any way applicable. I'm just thinking I might want to change from

tld.domain

as the group, to

tld.domain.gradle

as the group and maybe also

tld.domain.gradle.convention

as a way to group/distinguish purpose

you could also do similar to how the gradle plugin ID lookups work. its just an empty artifact and metadata that depends on the group:artifact the implementation is under

There is https://docs.gradle.org/current/userguide/publishing_maven.html#publishing_maven:relocation

thats absolutely how I'd go about this if I were you Caleb

that's probably basically what hibernate does

Hibernate is using Gradle