Capability patterns prescribe passing capabilities as parameters to a called function, (callee herein). Less often they prescribe revoking (or rescinding) those capabilities after the return from the callee. The capability in question is to the object herein. When should they prescribe revocation?
Generally it would be good to revoke after each call except for those cases where the agreed contract is for the callee to retain the capability for use subsequent to the call. Every capability system that I know imposes some extra cost to such revocation however and I consider here some situations where there is little or no advantage to revocation.
It is first necessary to try to enumerate the cases where the caller might be harmed by subsequent invocation to the capability. This enumeration may be incomplete.
This attack is no worse than the callee making the harmful modification during the call, unless the caller is in a position to, and can afford to examine the object after revocation to ensure no harm has been done. This is an unusual situation, I think, because the caller usually lacks the knowledge, or even authority, to do so (because of abstraction). Also the cost may be prohibitive. The check may be omitted as a mere oversight.
In some systems transient capabilities may exist which are produced by the call primitive and revoked by the return primitive, but such capabilities are another sort of animal; task switching must me somehow permitted to preserve these over scheduling events. Different sorts of capabilities are a large architectural expense. In the Algol68 case the procedure value passed is just such a transient value. For Scheme and Smalltalk the callee might retain the ability to modify ob after the return.