Add some clarifications based on @dabrahams' feedback.

Author: jckarter

proposals/XXXX-property-behavior-decls.md

@@ -386,6 +386,10 @@ x = 1 // Prints nothing
 x = 2 // Prints 1 => 2
 ```
 
+(Note that, like `didSet`/`willSet` today, neither behavior implementation
+will observe changes through class references that mutate a referenced
+class instance without changing the reference itself.)
+
 ### Synchronized Property Access
 
 Objective-C supports `atomic` properties, which take a lock on `get` and `set`
@@ -510,9 +514,42 @@ aspects of a property definition using the behavior:
   is evaluated when the binding is semantically loaded from (in other words,
   when its getter is called).
 
+Inside a behavior declaration, `self` is implicitly bound to the value that
+contains the property instantiated using this behavior. For a freestanding
+property at global or local scope, this will be the empty tuple `()`, and
+for a static or class property, this will be the metatype. Within
+the behavior declaration, the type of `self` is abstract and represented by the
+implicit generic type parameter `Self`. Constraints can be placed on `Self`
+in the generic signature of the behavior, to make protocol members available
+on `self`:
+
+```swift
+protocol Fungible {
+  typealias Fungus
+  func funge() -> Fungus
+}
+
+behavior var [runcible] _: Value
+    where Self: Fungible, Self.Fungus == Value
+{
+  get {
+    return self.funge()
+  }
+}
+```
+
+Lookup within `self` is *not* implicit within behaviors and must always be
+explicit, since unqualified lookup refers to the behavior's own members. `self`
+is immutable except in `mutating` methods, where it is considered an `inout`
+parameter unless the `Self` type has a class constraint.  `self` cannot be
+accessed within inline initializers of the behavior's storage or in `init`
+declarations, since these may run during the container's own initialization
+phase.
+
 Definitions within behaviors can refer to other members of the behavior by
 unqualified lookup, or if disambiguation is necessary, by qualified lookup
-on the behavior's name:
+on the behavior's name (since `self` is already taken to mean the containing
+value):
 
 ```swift
 behavior var [foo] _: Value {
@@ -523,11 +560,12 @@ behavior var [foo] _: Value {
   }
 
   mutating func update(x: Int) {
-    foo.x = x // Disambiguate reference to behavior storage
+    [foo].x = x // Disambiguate reference to behavior storage
   }
 }
 ```
 
+
 If the behavior includes *accessor requirement declarations*, then the
 declared accessor names are bound as functions with labeled arguments:
 
@@ -548,38 +586,6 @@ behavior var [fakeComputed] _: Value {
 Note that the behavior's own *core accessor* implementations `get { ... }`
 and `set { ... }` are *not* referenceable this way.
 
-Inside a behavior declaration, `self` is implicitly bound to the value that
-contains the property instantiated using this behavior. For a freestanding
-property at global or local scope, this will be the empty tuple `()`, and
-for a static or class property, this will be the metatype. Within
-the behavior declaration, the type of `self` is abstract and represented by the
-implicit generic type parameter `Self`. Constraints can be placed on `Self`
-in the generic signature of the behavior, to make protocol members available
-on `self`:
-
-```swift
-protocol Fungible {
-  typealias Fungus
-  func funge() -> Fungus
-}
-
-behavior var [runcible] _: Value
-    where Self: Fungible, Self.Fungus == Value
-{
-  get {
-    return self.funge()
-  }
-}
-```
-
-Lookup within `self` is *not* implicit within behaviors and must always be
-explicit, since unqualified lookup refers to the behavior's own members. `self`
-is immutable except in `mutating` methods, where it is considered an `inout`
-parameter unless the `Self` type has a class constraint.  `self` cannot be
-accessed within inline initializers of the behavior's storage or in `init`
-declarations, since these may run during the container's own initialization
-phase.
-
 ### Nested Types in Behaviors
 
 Behavior declarations may nest type declarations as a namespacing mechanism.
@@ -681,28 +687,28 @@ accessor-requirement-decl ::=
 
 An accessor requirement declaration looks like, and serves a similar role to,
 a function requirement declaration in a protocol. A property using the
-behavior must supply an implementation for each of its accessor requirements.
-The accessor names (with labeled arguments) are bound as functions within
-the behavior declaration:
+behavior must supply an implementation for each of its accessor requirements
+that don't have a default implementation. The accessor names (with labeled
+arguments) are bound as functions within the behavior declaration:
 
 ```swift
 // Reinvent computed properties
-behavior var [computed] _: Value {
-  accessor get() -> Value
-  mutating accessor set(newValue: Value)
+behavior var [foobar] _: Value {
+  accessor foo() -> Value
+  mutating accessor bar(bas: Value)
 
-  get { return get() }
-  set { set(newValue: newValue) }
+  get { return foo() }
+  set { bar(bas: newValue) }
 }
 
-var [computed] foo: Int {
-  get {
+var [foobar] foo: Int {
+  foo {
     return 0
   }
-  set {
-    // Parameter gets the name 'newValue' from the accessor requirement
+  bar {
+    // Parameter gets the name 'bas' from the accessor requirement
     // by default, as with built-in accessors today.
-    print(newValue)
+    print(bas)
   }
 }
 
@@ -763,7 +769,7 @@ a behavior declaration does not provide at least a getter.
 
 ### Using Behaviors in Property Declarations
 
-Property declarations gain the ability to declare a behavior,
+Property declarations gain the ability to instantiate behavior,
 with arbitrary accessors:
 
 ```text