Consider:

<xs:complexType name="e">
  <xs:openContent>
    <xs:any namespace="http://wild.com/"/>
  </xs:openContent>
  <xs:sequence/>
</xs:complexType>

Working through the rules in 3.4.2.3.3:

1. The effective mixed is false

2. The explicit content is empty

3. The effective content is empty

4. The explicit content type is: (variety=empty, particle=absent, open-content=absent, simple-type-definition=absent)

5. the wildcard-element is the openContent element

6. Therefore the {content type} property is (variety=empty, particle=<sequence/>, open-content=(<xs:any/>, interleave), simple-type-definition=absent)

So the rules seem to go to some lengths to ensure that the {content type} includes the open content. This would be even more true if the open content were derived from a <defaultOpenContent> with appliesToEmpty=true.

But now look at the validation rules in 3.4.4.2. Rule 1 is:

1.1 If T.{content type}.{variety} = empty, then E has no character or element information item [children].

That is, it doesn't make any difference what {content type}.{open content} says, the element is only valid if there are no children. Only if {variety} is mixed or element-only do we invoke Element Sequence Locally Valid (Complex Content) (§3.4.4.3), which is where {open content} comes into play.

I find it hard to believe this was intended, especially given the attribute appliesToEmpty.

Also it seems we have carefully constructed a complexType schema component that violates the constraint in 3.4.6.1:

5  If {content type}.{open content} is ·non-absent·, then {content type}.{variety}  is either element-only  or mixed.

I'm not sure what the right fix is. It might be to make variety=element-only in this case. But this would also have effects on deriving types by extension, and I haven't begun to study in detail what happens when types with open content are extended. 

(Incidentally, another consequence of the current rules is that a defaultOpenContent applies to 

<xs:complexType name="e" mixed="true">
  <xs:sequence/>
</xs:complexType> 

whether or not it specifies appliesToEmpty="true". I don't know if this was the intention. But it does no harm.)