Agreed, although I'd classify it as a design flaw more than a bug. I think the correct design of the overwrite behavior would be to only evict cookies of the same HttpOnly value when a new cookie is set that causes the number to overflow. If that's not possible, then it should throw an error.
Design flaw would be if the specification implied that manipulation of cookies through non-HTTP APIs could affect the HttpOnly cookies. But it only says: "the attribute instructs the user agent to omit the cookie when providing access to cookies via "non-HTTP" APIs". So, the browsers really should "omit" it, that is, not affect it directly by scripted manipulation of cookies in any way. Yes, "omit the cookie" feels a little vague, but I'm also not sure that the specification authors should be blamed for this wording.
Yup, this is something that is frequently not talked about.
HttpOnly merely prevents the theft of the cookie via XSS. It doesn't prevent an attacker from performing operations on behalf of the user via XSS.
That said, it does make the attack slightly harder. You have to write a bespoke attack script, rather than just a nearly universal one-liner to steal the cookie and then take over from there. In addition, if the victim navigates away from the page, then the attack ends. Of course, most likely, the attack script will only need a few seconds at most to complete the attack script.
