The term "capability" is perfectly appropriate here. A capability is something that defines how you can use what it points to. It's often used in the security context, but is also used the way Pony uses them (to define how the holder of a reference can mutate the target object).
A capability is traditionally a noun, or sometimes the combination of a noun and a set of allowable verbs, but not simply a verb.
If Pony were using "capability" to describe the combination of a variable and its qualifiers, then I'd say, yes, that's a capability -- it designates a thing, and the permission to use it. But they are using "capability" to describe specifically the _qualifiers_ on the variable, which is not correct, and is confusing.
Before you ask: Yes, Linux/POSIX capabilities (as described on the capabilities(7) man page) are similarly misnamed. This is covered in the paper, and has been a source of a lot of confusion.
FWIW, this is a touchy subject for a lot of fans of capability-based security because the story of capabilities goes something like this:
1960s-1970s: Capability-based security invented, popularized, widely used, almost makes it into hardware (Intel 432).
1980s-1990s: People incorrectly redefine capabilities in various ways (e.g. as verbs rather than nouns), then declare "capability-based security doesn't work" based on these misunderstandings (see the paper I linked). Capability systems find they have trouble making headway against these misconceptions, as the difference between the misconceived version and what capabilities really are are just subtle enough to confuse anyone who isn't immersed in it. (Meanwhile, the basic ideas of capabilities live on as object-oriented programming, but aren't enforced strictly enough to be called "security".)
2000s-2010s: People start realizing that capabilities as originally defined do in fact work ridiculously well and they become re-accepted.
