Worker plugins use a name which is useful for unregistering. As of now the scheduler plugins are stored in a Python list, so right now I can image removal perhaps being a bit tricky without a name. Should we work on supporting named scheduler plugins?

The idempotency logic currently uses types to infer whether a plugin is already there or not. The remove, however, is a bit more simple and only works if you are trying to remove the identical instance so there is room for improvement.
I'd be open for a named plugin system but am a bit afraid of the idempotency problem and am wondering if this is worth it or if it makes everything more difficult to use if we introduce names. What if people try to register the same plugin but using a different name? What if there are different plugin types trying to use the same name?

Thanks for the updates @douglasdavis! Apologies for the delayed review, this PR is looking good

Worker plugins use a name which is useful for unregistering. As of now the scheduler plugins are stored in a Python list, so right now I can image removal perhaps being a bit tricky without a name. Should we work on supporting named scheduler plugins?

That's a good point. I think we should work on supporting named scheduler plugins similar to how we already treat worker plugins. Though initially we'll want to have some compatibility code to support the current behavior so there's a smooth transition for any current users of Scheduler.remove_plugin.

Thanks @douglasdavis! If we’re going to have a Client.unregister_scheduler_plugin, then I’d like to see us move towards using named scheduler plugins / storing them in a dictionary on the scheduler instead of a list (similar to how we treat worker plugins today) and removing them by name instead of by instance. I think this will make thing easier to reason about once users are able to register scheduler plugins from the Client process.

Also, depending on how you're feeling, we can not worry about Client.unregister_scheduler_plugin for now. We could just limit the scope of this PR to registering scheduler plugins and take care of unregistering them in a later PR. We can definitely include that functionality here, but I just wanted to give you an exit opportunity in case there are other things you're interested in working on.

Just left some final comments, but overall this looks good

Thanks @douglasdavis! Just one minor comment, otherwise this is good to merge

Thanks @douglasdavis! This looks great, will merge after CI finishes