The design consideration was not that it had to be simple to implement. It's that it had to be easy to parse by a human during an outage when nothing else works.

It's a little bit of both. Simple to implement, simple (and fast/cheap) to parse, and human readable.

There are a frustrating number of fundamental corner cases due variance to floating point text formats, and slightly more in the descriptor if you also need that. It's simple to implement an expositor for a limited set of cases. As usual, it's much more difficult to parse what you actually find in the world.

Maybe I'm being downvoted for insufficient examples? OK, here's a big one:

OpenMetrics's production rule for the format says:

    labels = "{" [label *(COMMA label)] "}"

And yet, the Prometheus Java client library exports a trailing comma with no subsequent label.

As for fp, I've seen parsers break on `e` v. `E`, and `NaN`/`Inf`/ vs. `nan`/`inf`. The latest IETF draft even has a comment,

     ; Not 100% sure this captures all float corner cases.

Control characters are allowed in descriptors and label values and no normalization form is specified.

Yea, there still some corner cases and implementation bugs out there. We spent months deliberating how to deal with some of these. Because the base libraries in some languages just don't produce string output from IEEE 754 the same way.

IIRC, Java is different from Python is different from Go. So, really, this is a standardization in languages problem. We tried to work around these as best we could in the OM format.