I don't have a solution for unifying the concept escapability. I'll just outline some of the differences.
_effects annotations are completely unsafe compiler hints that make promises about a function implementation. (I'm sure a better syntax is possible. If we ever surface them as a language feature they'll at least need "unsafe" in the name). They simply have no affect on the programming model--they don't change where or how you can call the function, and don't even change the code you can write in the implementation. They just declare certain things the implementations might do to be undefined behavior.
@nonescaping/@escaping modifiers also make promises about a function implementation, but they are exposed to the API and ABI, and they change the programming model for closures. They exist to (1) allow more freedom in the implementation of escaping closures and (2) allow the compiler to use a more efficient ABI when passing nonescaping closures. They are restricted to function type arguments and do not take part in the generic type system. These argument type modifiers do not say anything about the capabilities of a type. All function types are escapable, which is why the withoutActuallyEscaping API can be used to reverse nonescaping-ness. So, "locally nonescaping" is really a special feature of function types. This feature could be extended to non-function types as well. But... the polarity would be reversed, causing confusion, and "locally nonescaping" values would be incompatible with all generic code. You could never pass them off a some P or any P. This just doesn't get us where we need to be for "view types".
~Escapable is a capability of the type. Unlike the previous two concepts, it is an intrinsic property of a type that is not context dependent. There is no way to add escapability to a type. withoutActuallyEscaping won't work. This is what allows compatibility with generic types. The arguments for why ~Escapable needs to be a negative capability rather than a local constraint are all the same as the arguments for making ~Copyable a negative capability rather than adding a moveOnly local constraint. Some discussion on that is here:
I expect more discussion soon, once generic support for NonCopyable is pitched.