The way I would suggest to handle this with OpenMetrics is to fetch the metrics. It is intended that all the useful information is in-band and all available metrics should be exported, even if the metric family is empty right now. Expecting developers to expose metrics in two different ways is a bit hopeful I suspect, there's already challenges with getting metrics exported correctly one way - and if they're exported correctly that way then the information is already in the returned metrics as a given metric family should always be exposed.
Load is down to cardinality more than anything, a list of metadata is unlikely to tell you which metrics may be problematic in that regard.
Good spot, thanks for fixing!
From a very quick glance this looks okay for a future OM 2.0, other than the
schema being required as the old way should still work. It probably only needs a little verbiage in the comments on how to tell which way is in use.
We may wish to do the renamings of the existing fields now in 1.x, to avoid future hassle when things are harder to change. I'm okay with that in principle as it should be fairly low impact now, however it may count as a breaking change. If the current Go accessors aren't right, we should probably fix that in 1.x though.
That section of the spec is about the data model, not the wire format.
We don't force empty lines.
From my Slack with Julien just now: I believe it should be
The current wording is what you argued for. The text is saying that the values must always be present, but HELP and UNIT can be empty.