Generally plugins that are specifically designed to act upon the registry, should live under the registry group (it was supposed to be an example of how we could categorize plugins, but then no one ever really did it with any of the other plugins). As to moving a plugin, I guess you leave a class that inherits under the old name, but with a deprecation warning? Then two or three releases later (after people are using the new one), we can ditch the old one. Since it's a new plugin, technically it can have its version bumped back to 1.0.0, but I might leave it at whatever it's at for simplicity? All core plugins should be updated to use the new one (not the deprecated one). Does that answer all the corner cases, or have I missed some?

That sounds good. I was make sure the test cases are valid for the new ones.

As for the deprecation -- if the current file inherits from the new file under registry/, where would the deprecation warning go.?I assume we want it in run(), so would the existing file override run to be the same except adding the warning?

Yeah, basically run would be:

def run(self, *args, **kwargs):
    warnings.warn(DeprecationWarning('This plugin is now called BLAH'))
    return super().run(*args, **kwargs)

Actually, thinking about it, we probably want it under __getattr__ or something, so that class methods would get caught? warning.warn would ensure the warning's only issued once, but just so we get visibility over dependencies. We'd probably need to leave out get_requirements but otherwise...