Major changes in draft-ietf-imapext-list-extensions-09

I've just submitted LISTEXT-09, that should be announced soon.
Below is the list of changes:

1). Add a requirement that the MATCHPARENT selection option can't be 
used as the only selection option (as per Cyrus Daboo suggestion):

          The MATCHPARENT option MUST NOT occur as the only selection 
option,
          as it only makes sense when other selection options are also used.
          The server MUST return BAD tagged response in such case.

2). Removed the REMOTE return option as it is redundant (as per recent 
post by Dave Cridland)

3). Clarified the purpose of selection options and return options. 
Clarified how multiple selection options can interact.

4). Clarified when a server implementing another extension that depends 
on LISTEXT has to return the LISTEXT capability in a CAPABILITY response.

5). Clarified the purpose of \Placeholder and \HasSubmailboxes flags.

6). I've changed all occurrences of "flag" to "attribute", to be more 
consistent. I've noticed that the RFC 3501 mostly uses the term 
"attribute", but sometimes (especially in ABNF comments) it uses the 
term "flag".

7). Added a new section with additional requirements on clients:

   All clients that support this extension MUST treat an attribute with
   a stronger meaning, as implying any attribute that can be inferred 
from it.
   For example, the client must treat presense of the \NoInferiors attribute
   as if the \HasNoChildren attribute was also sent by the server.

And added a table at the end that summarizes all described "inference" 
rules.

8). Various other editorial changes and clarifications (in particular 
"s/match option/selection option" and updated the text to use "mailbox 
name" instead of "mailbox" where appropriate). I've also added more 
examples. Can somebody check the example #8 and #9 in the new draft? Is 
the example #9 useful?
========
I have two new minor issues to discuss (actually, we kind of discussed 
one of them a bit):

1). Do we need to add a special section for unsolicited responses?
Do we want to require properly computed \Remote and \Subscribed
attributes in all unsolicited LIST responses?

(I tend to answer "yes". This should even work with unextended LIST, as
all clients should ignore unrecognized mailbox attributes.)

2). There is the following text in the current LISTEXT draft:
 >   In some instances a server that supports the Child Mailbox Extension
 >   might not be able to determine whether a mailbox has children.  For
 >   example it may have difficulty determining whether there are child
 >   mailboxes when LISTing mailboxes while operating in a particular
 >   namespace.

Should the same be done for \HasSubmailboxes/\PlaceHolder?
(I tend to say "no", but some people might argue that this is additional
burden for server implementations).

Alexey