Thanks for your response ikedam and thanks for the prompting questions. I'll follow the pattern that Basil and others have used and will create a Jira epic to capture the issues for other plugins. That will allow multiple Jira issues to be grouped in a single page with the details about implied dependencies in that single page.
What is an implied dependency?
Implied dependencies are described on the plugins.jenkins.io site in the "What's this?" text as:
Features are sometimes detached (or split off) from Jenkins core and moved into a plugin. Many plugins, like Subversion or JUnit, started as features of Jenkins core.
Plugins that depend on a Jenkins core version before such a plugin was detached from core may or may not actually use any of its features. To ensure that plugins don't break whenever functionality they depend on is detached from Jenkins core, it is considered to have a dependency on the detached plugin if it declares a dependency on a version of Jenkins core before the split. Since that dependency to the detached plugin is not explicitly specified, it is implied.
Plugins that don't regularly update which Jenkins core version they depend on will accumulate implied dependencies over time.
In most cases, the plugin that has the implied dependency will not stop working when the WMI Windows Agent plugin is removed. However, the user cannot be confident of that until they've removed the WMI Windows Agent plugin and confirmed that their system is still operating as expected.
Why is WMI Windows Agents plugin deprecated?
The reason for the deprecation of the WMI Windows Agents plugin is included on the plugin page where it says:
This plugin is deprecated. SSH is now a very viable, secure and robust solution for connecting to Windows based agents using native Windows binaries for OpenSSH Server or another method such as cygwin. There is also the Windows Cloud plugin for Jenkins which uses WinRM, a more modern remote management solution.
The method for connecting agents to the controller in this plugin, which is based on DCOM, has several pitfalls and issues and can be brittle. The SSH and other solutions can unify the method for connecting to all agents (Windows, Linux, macOS, etc.) in your infrastructure. It is highly recommended that you migrate to one of these other methods sooner rather than later.
Microsoft is tightening security on DCOM based on a CVE. Initial OS updates will require a registry change to enable the current security level, then in May of 2023 they will not have a way to override the secure behavior. The library used in this plugin was last released in ~2010 and does not have an active development team. Jenkins developers have decided to deprecate this plugin rather than try and maintain the library on our own.
Why does the implied dependency exist?
An implied dependency exists because Jenkins core does not know if the dependent plugin requires functionality that was moved from Jenkins core to the WMI Windows Agent plugin when the WMI Windows Agent plugin was split from core. The WMI Windows Agent plugin was split from Jenkins core in release 1.547. Plugins that declare a dependency on a version of Jenkins core before the split are given the implied dependency by Jenkins core. It is "implied" because it is not directly declared in the plugin and it is a dependency because Jenkins core does not know if the API's that were in Jenkins core before the split of the plugin are required or not.
How can the implied dependency be removed?
The implied dependency can be removed by releasing a new version of the plugin that depends on a newer minimum Jenkins core than Jenkins 1.547. The "Improve a plugin" tutorial provides steps that can assist plugin developers as they configure the plugin to depend on a newer minimum Jenkins core.
See the tracking sheet that I'm maintaining for the plugins with implied dependencies on WMI Windows Agents