The use of "intersection" to describe the operation approximated in section 4.5 is problematic.

Intersection usually refers to set intersection of some sort (it might also refer to bag intersection, given that at least some collections in WS-P are bags).  Assuming that policies are sets (see 4552), there is some resemblance between set intersection and policy intersection, in that if it so happens that alternatives are compatible only when they're identical, the intersection of two policies will contain one item for each of the alternatives in the set intersection of the two policies.  If intersection of alternatives turns out to mean bag intersection (see 4553), then in this particular case policy intersection will be the set intersection of the two policies.

However, if these exact conditions don't hold, then the result is not at all the set intersection of the two polices.  In particular, two alternatives with the same assertions but different multiplicities will be compatible, and alternatives may be compatible even if their component assertions are not identical, if the assertions are of the same type (or are ignorable in the case of lax intersection).  In such cases the result may have more alternatives than either of the policies being intersected, which is counter-intuitive to say the least.

In short, it seems misleading to call "pairwise combination (see 4553) of compatible alternatives" "intersection", even though it does in some cases act like intersection.