Replacing `github.com/rcrowley/go-metrics` with `github.com/prometheus/client_golang`?

While working on https://github.com/palantir/go-githubapp/pull/438, I came across https://github.com/rcrowley/go-metrics.

I came across two areas:

Shortcomings

1) Maintenance

See https://github.com/rcrowley/go-metrics/issues/291
The project github.com/rcrowley/go-metrics is no longer maintained; the last commit was 5 years ago.

2) Support for proper labels / tags

https://github.com/rcrowley/go-metrics as well as https://github.com/deathowl/go-metrics-prometheus doesn't seem to support labels.
See https://github.com/rcrowley/go-metrics/issues/135 and https://github.com/deathowl/go-metrics-prometheus/issues/6

Currently, this is represented in the Metrics client middleware as ... (using Prometheus as output format):

# HELP sourcectl_worker_github_rate_used_installation:12345_ github.rate.used[installation:12345]
# TYPE sourcectl_worker_github_rate_used_installation:12345_ gauge
sourcectl_worker_github_rate_used_installation:12345_ 1

In a prometheus native way, this would look like

# HELP sourcectl_worker_github_rate_used_installation:12345_ github.rate.used[installation:12345]
# TYPE sourcectl_worker_github_rate_used_installation:12345_ gauge
sourcectl_worker_github_rate_used{installation=12345} 1

If you want to expose the installation as label, this is a different question, as this is (depending on your use case) a high cardinality value (e.g. if you run it through a lot of installation).

Another shortcoming is the missing / or more unhelpful HELP text.

rcrowley/go-metrics is more than just Prometheus

I know that rcrowley/go-metrics is a generic metric implementation and not Prometheus-specific.
In my setup, I am using Prometheus and the not existing label support is a drawback here.
I do understand that other users of this lib (or even Palantir itself) may not have a Prometheus setup.

Own Middleware or PrometheusClientMetrics Middleware

It is possible for me to write my own Middleware and also contribute it back to this project.
Maybe as a separate PrometheusClientMetrics Middleware.
This would not break the existing go-metrics usage.
It could also be that you decide to release a new major version and run with the breaking change. Here, I do not have insights how you think about it (and what effect this would have on your internal implementations).

I would like to get a bit of feedback on this from you and your thoughts around this.

Start by reviewing the Metrics client middleware and its existing github.com/rcrowley/go-metrics integration, then compare the proposed Prometheus client_golang approach with the current Prometheus output. Before implementation, clarify whether the project wants a separate Prometheus middleware or a breaking replacement; done requires an agreed migration scope and label and HELP-text behavior.