diff --git a/proposals/1772-groups-as-rooms.md b/proposals/1772-groups-as-rooms.md
index d3a6cefd7..3bfdd8bcd 100644
--- a/proposals/1772-groups-as-rooms.md
+++ b/proposals/1772-groups-as-rooms.md
@@ -153,9 +153,11 @@ relationship can be expressed in one of two ways:
     space that it should not be, clients could ignore such `m.space.parent`
     events unless either (a) there is a corresponding `m.space.child` event in
     the claimed parent, or (b) the sender of the `m.space.child` event has a
-    sufficient power-level to send such an `m.space.child` event in the parent.
-    [Checking the power-level rather than requiring an *actual* `m.space.child`
-    event in the parent allows for "secret" rooms (see below).]
+    sufficient power-level to send such an `m.space.child` event in the
+    parent. (It is not necessarily required that that user currently be a
+    member of the parent room - only the `m.room.power_levels` event is
+    inspected.) [Checking the power-level rather than requiring an *actual*
+    `m.space.child` event in the parent allows for "secret" rooms (see below).]
 
     Where the parent space also claims a parent, clients can recursively peek
     into the grandparent space, and so on.
@@ -292,6 +294,13 @@ None at present.
   different querying users. (It may be possible to simulate this behaviour
   using smaller spaces).
 
+* The requirement that `m.room.parent` links be ignored unless the sender has a
+  high PL in the parent room could lead to suprising effects where a parent
+  link suddenly ceases to take effect because a user loses their PL in the
+  parent room. This is mitigated in the general case by honouring the parent
+  link when there is a corresponding `m.room.child` event, however it remains
+  a problem for "secret" rooms.
+
 ## Rejected alternatives
 
 ### Use a separate state event for type of room