Tweak the equivalence example, explain why a nested suite is a bad idea

pep-0403.txt

@@ -130,12 +130,14 @@ cases where the local name binding isn't actually needed.
 
 Under this PEP, an ordinary class or function definition::
 
+    @deco2
+    @deco1
     def name():
         ...
 
-would be equivalent to::
+can be explained as being roughly equivalent to::
 
-    @in name = name
+    @in name = deco2(deco1(name))
     def name():
         ...
 
@@ -214,6 +216,27 @@ reference to the associated function or class definition without creating an
 actual name binding in the current scope.
 
 
+Why not a nested suite?
+-----------------------
+
+The problem with using a full nested suite is best described by reviewing
+PEP 3150. It's ridiculously hard to implement properly, and creates way
+too many situations where there are two ways to do it (almost any construct
+that can be expressed with ordinary imperative code could instead be
+expressed using a given statement).
+
+By contrast, the decorator inspired syntax explicitly limits the new
+feature to cases where it should actually improve readability, rather than
+harming it. As in the case of the original introduction of decorators, the
+idea of this new syntax is that if it *can* be used (i.e. the local name
+binding of the function is completely unnecessary) then it *should* be used.
+
+While a non-decorator based alternative could be considered (e.g. a nested
+"suite" that actually allowed only a single class or function definition),
+it seems excessive to introduce a completely new concept when it is
+possible to use a variant of the existing decorator syntax instead.
+
+
 Keyword Choice
 --------------