WS-Policy Framework and attachment define a number of elements with element extensibility.  Where the extensibility is provided, the form is for elements from ##other namespace.  The elements with their current element extensibility is:

Policy: element from ##other namespace
PolicyReference: None, with a proposal to add any element, the use of ##other vs ##any spawned this issue.
ExactlyOne, All: element from ##other namespace
PolicyAttachment:  element from ##other namespace
AppliesTo: element from ##any element

Policy, ExactlyOne, All, PolicyAttachment all of have optional children defined in their content model.  Interestingly, the PolicyAttachment would like to refer to wsse:Security but it can't because of a UPA conflict between the ##other and wsse:Security.  There already is an example of where an element reference is omitted from the schema because of a UPA violation.

AppliesTo allows element from ##any namespace.  Interestingly, it's not clear what an AppliesTo that had an element from WS-Policy ns would mean.  

All the elements that have attribute exensibility have ##any attribute extensibility.  

There is a separate issue, 3590, to add element extensibility to PolicyReference.  This brings up the issue of which namespace should it be, ##any or ##other.  

An argument has been made that ##other is the consistent approach for extensibility in metadata specs.  That precludes the creation of new names in the current namespace.  

My counter argument is that the extensibility architecture is actually:
1) Use ##any for all extensibility where possible,
2) else use ##other.
3) Where ##other conflicts with a particular element, remove the element from the content model.

In the case of PolicyReference, there are no optional elements in the target namespace, therefore ##any should be used.

Given that ##any is used for attribute extensibility, which means a new attribute name can be added into the existing WS-Policy namespace, I don't see why a new element name can't be added.  

There is another alternative approach that is consistent, which is to have all the elements have ##any namespace including exactlyOne and All, and then remove those elements from the pertinent content models, ala wsse:Security nonInclusion.

One key question is how much of the validation of Policy element content is done by schema validation versus custom Policy logic.  There are many rules defined for processing Policy constructs above and beyond the arguably simplistic schema constraints.  I tend to think the schema is not terribly constraining or useful.  

I see 3 options for element extensibility:
1. Use ##any and remove all optional element refs.  
2. Use ##any where possible, ##other elsewise, remove all ##other optional element refs.
3. Use ##other everywhere, remove all ##other optional element refs.

I can live with any of these, and order of preference is #2, #1, #3.