Proposal

new-service-discovery-manager has been introduced in #9349 and #9537, it's hidden behind --enable-feature=new-service-discovery-manager.

I expect this new manager to be widely adopted by third parties (consumers that use prometheus as a library), as the default manager has been relocated to github.com/prometheus/prometheus/discovery/legacymanager. I don't think they transitioned or have been using a "legacy" dependency without raising any concerns :)

The default legacy manager has known limitations/bugs:

• It recreates/discovers targets from scratch on each config apply (/-/reload). In some setups, this "causes unnecessary scrape disruptions": Service discovery provider should not be reinitialized on /-/reload if its config is unchanged #9321. This limitation was the driving force behind the changes that resulted in the new manager.
• With file SD, targets from a deleted file are not dropped if a reload is triggered just after the deletion File discovery not remove targets sometimes #12007.

Bugs that affect both managers:

• Receivers are not notified about dropped targets: kubernetes_sd does not remove existing targets when an existing config is modified to produce an empty result #12858 - fix(discovery): make discovery manager notify consumers of dropped targets for still defined jobs #13147 suggests a fix for the new manager only.
• The targets map is leaking: Using Prometheus SD as a library did not work as expected #12436 - @machine424 has an idea for a fix for the new manager that needs fix(discovery): make discovery manager notify consumers of dropped targets for still defined jobs #13147

Considering all these factors, let's discuss the new-service-discovery-manager promotion.