Ah, but underestimatedCount doesn't share your proposed semantics: it is not required to be close to the actual count, but it is absolutely required to be underestimated—indeed, for many types where the count is not easy to estimate, one should estimate either 0 or (if known non-empty) 1, even if one can be quite sure there are many, many values.
Hence why I ask: with your proposed API, should one err towards overestimating or underestimating, and how is a user to know when they're potentially "close enough" versus too off-the-mark and instead should return nil?
Put another way: should instead your API actually be designed more like underestimatedCount, such that it doesn't rely on a notion of being "close enough"?
The scenario you articulate applies equally to all protocol requirements, not just associated types: for example, the Collection protocol has count, but that might interfere with what a non-collection protocol would reasonably want to call count—yet we don't prefix everything in Collection (for example, collectionCount).
In general, we have said that users 'discover' conformances by finding that their concrete type happens to align with protocol requirements. It would be unusual indeed for a type to be discovered to have the correct semantics for conformance to two distinct protocols but be frustrated because both have semantically different WrappedValue associated types, assuming each is aptly named: that would mean that a single type serves as a sort of wrapper for two different values of two different types. This doesn't sound to me like a scenario that would require special accommodation as an exception to our usual approach of not pessimizing protocol requirements with prefixes.
(Your argument would, on the other hand, come to the fore in the scenario of Attachable itself, which seems like a protocol to which all or nearly all fundamental types are expected to conform as table stakes; but Attachable[Container|Wrapper] isn't such a protocol.)
Not—I hope you would agree—a positive direction for the ecosystem to have the same term used for unrelated features. Where it can be reasonably foreseen, such as with "container," it would be wise for us not to dig ourselves into that hole again.
That makes sense in context. However, in that case, there's another convention which I think we ought to observe here: where we name a property with a lowercase version of a type, it should be of that type (see, for example, span being of type Span). If not in alignment, then the property should be otherwise named: that is, it should not be called attachableValue if there's an associated type AttachableValue and the property does not (always) give you an instance of the type.