One of the things about the extension list module - is that in terms of things like providers
- it does not really do any sort of validation or tracking of what providers are actually working on the system.

Part of the reason for this - is that providers are technically controlled for the most part by the portals web.config file - and not by dnn itself.
The list of providers that are shown in the extensions list - really just represents a list of logging records that were created when a provider extension is installed.

As such - its possible for providers to be on the list - and not running or active
the providers .dll files can be still in the /bin/ folder
- but if the markup code is not in the web.config then the provider is not technically installed as far as dnn is concerned.

DNN itself keeps a track of its core providers and keeps them up to date - but the idea of providers means that there can also be 3rd party providers that do their own thing as well.

BUT basically the ONLY valid place to look to verify what PROVIDERS are installed on a system is in the web.config file.

As an example - in you list - DotNetNuke Core Site Map provider - listed as 5.6.0.
Back before DNN 6x the dnn core site map provider was installed as a separate dll and as such this entry relates to that older provider installer.
What it did was copy the correct dll into the system and make the entries that were required in the web.config.

But in the current implementation of DNN the core sitemap provider code is actually compiled as a part of the dotnetnuke core library.
As as such does not have a separate installed any more.

If you dig into the web.config - you will see the entry for the core provider maps to DotNetNuke.Services.Sitemap.CoreSitemapProvider which in the source is part of the dotnetnuke.library.

If you were to try and hit delete on the old 5.6.0 version - it could actually cause problems - depending on what code was in the uninstaller -- many of the provider uninstallers try to make changes to the web.config - and running this old installer could cause entries to be deleted from the web.config that should still be there.

Part of the reason for this complexity is that - the uninstaller for an old version could not possibly KNOW about changes made in a future edition of DNN.

As i said previously - if it isnt broke then its maybe a good idea to leave that area alone.

that would be why i said - for the most part -  but yes i agree with sebastian - its a bit of a messy area - because there always seems to be exceptions to any rule - specially with dnn

Yeah - legacy dnn sites tend to build up baggage over time - the upgrade system does a pretty good job of trying to keep things sane - but with so many thousands of possible combinations of configurations - some things can slip thru the cracks.