[ This issue is a mishmash of a question, feature request and bug report. Unclear what category it fits best. Closely related to, but different from #10542 ]

Presently, when reporting the nominal bit counts of ECDSA private or public keys as part of the "TEXT" output format (e.g. with openssl pkey -text ...), the value used is the raw bit count of the order $n$ of the group's base point (element count of the generated cyclic group, i.e. the number of possible distinct private keys).
This is quite reasonable in the many cases in which the order is just below a power of two (when the group order is $2^k - ε$ the reported bit count is $k$).
It is at least somewhat surprising to report $k+1$ when the group order is $2^k + ε$. Yes it takes $k+1$ bits to represent the exact order, but what's relevant in terms of the key's security is that there are roughly $2^k$ possible private key values. The entropy of a uniform distribution over the private keys is essentially $k$, not $k+1$.

So perhaps we should round towards the nearest power of 2 (on a log scale), mapping $2^k \pm ε \rightarrow k$.

This would result in reporting 1 bit less for the curves listed below.

[ In some of the cases the group order is quite far from a 2-power, it is instead approximately ${4/3} \cdot 2^k \pm ε$ with a fractional entropy of $\log_2 (4/3) \sim 0.42$. These are also rounded down.
If rounding the key space entropy bits to the nearest whole number is not your cup tea, what should be reported instead? ]

ECC Named Groups: Order and Entropy Mapping

The table below shows curves whose current reported key bit count matches the rounded entropy bits.
The last 15 entries are rounded up non-trivially from a fractional part of ~0.6–0.9.

(Unchanged) ECC Named Groups: Order and Entropy Mapping