To be fair, the limit is part of the API's semantics. If the limit is undocumented, the API is at least partly undocumented. It's as if a car had a headlights button that the manual had this to say about it: The headlights button turns on the headlights and the headlights indicator light on the dashboard. However, nothing in the manual states that the headlights indicator shares a circuit with a valve that drains the fuel tank, so in effect when you turn the headlights on, you're causing the fuel to leak. I would say the button is not properly documented in that case.

You're stretching too far in your attempt to be fair.

When people talk about using undocumented APIs in windows, that means secret APIs, not badly documented APIs. That is the only meaning that fits the accusatory tone of the comment.

I agree. That's why I didn't say that the feature was undocumented, but that it was improperly documented. I also don't agree that it's right to blame the user for using a feature that's not properly documented, since the user has no way of knowing that.

Then I'm not sure why you said "to be fair[...]partly undocumented".

Isn't the thing you being fair to the last line of mrguyorama's comment? The one that was blaming the user? The thing you replied to was an argument over the appropriateness of that specific line.

"To be fair" because neither "it's documented" nor "it's undocumented" capture the state of things. I'm highlighting why someone would consider the API not fully documented to make it easier for others to see mrguyorama's point of view, even if I disagree with it. In other words, I'm steelmanning their argument, since I think it was poorly put forward.

It's only steelmanning if that's what they meant, and I don't think that's what they meant.

Trying to strengthen an argument by finding a way that a word could technically work, but not with the original implications, isn't very helpful. I'd even argue it hurts clear communication in a situation like this.