We obviously need better documentation and other resources to teach these concepts.
But the relationship between the feature we're reviewing here and Sendable is actually pretty well captured exactly by what you mention here.
When a type conforms to a Fooable protocol, it's a guarantee that every value of that type can be fooed, but it isn't to the exclusion of other values (of non-conforming types) that may also be fooed. For a recent example, not every bitwise copyable value is of a type that conforms to BitwiseCopyable; but every value of a BitwiseCopyable type is bitwise copyable.
And so likewise, while every value of a Sendable type can be sent, also "non-Sendable types values can in fact end up being 'sent' ... (and in fact, that's the point of the keyword)." In fact we just adopted this feature in a mutex API proposed in SE-0433 precisely because transferringsendable was an appropriate relaxation of the originally proposed Sendable requirement.
We aren't confused by what SignedInteger is just because some values of floating-point types are also integers (which are signed), nor are we confused by what RandomAccessCollection is just because some string values can also support efficient random access (e.g., ASCII strings).
I'm not particularly married to sendable as the spelling for this feature, as opposed to (say) sending or sent, but I do vastly prefer something of that ilk, because it is precisely the point that we are describing the sending of a value across isolation regions.
The terminology we use to describe what the Fooable protocol guarantees to every value of a conforming type should be called "foo(-ing, -ed, -able)"; it doesn't make sense that for region isolation specifically we have to cast about for an alternative word so that Fooable guarantees that all values are "florpable" simply because non-Fooable values might be "florpable" too.