You have several options, all with some drawbacks.
You can rewrite the nested sequence to require at least one fruit this way:
<xs:choice>
<xs:sequence>
<xs:element ref="Cherry"/>
<xs:element ref="Durian" minOccurs="0"/>
<xs:element ref="Elderberry" minOccurs="0"/>
<xs:element ref="Fig" minOccurs="0"/>
</xs:sequence>
<xs:sequence>
<xs:element ref="Durian"/>
<xs:element ref="Elderberry" minOccurs="0"/>
<xs:element ref="Fig" minOccurs="0"/>
</xs:sequence>
<xs:sequence>
<xs:element ref="Elderberry"/>
<xs:element ref="Fig" minOccurs="0"/>
</xs:sequence>
<xs:sequence>
<xs:element ref="Fig"/>
</xs:sequence>
</xs:choice>
(I've omitted the default values of minOccurs and maxOccurs to make the difference between minOccurs="0" and minOccurs="1" stand out more.)
This is dramatically simpler than the corresponding problem when the designer insists on not prescribing an order. But it may still feel kind of bulky.
You could go with your nested-choice design and specify, at the application level, that the only thing that matters is the presence of a given fruit, not the number of times it's present, so <Fruits><Cherry/><Cherry/><Fig/></Fruits>
is semantically the same as <Fruits><Cherry/><Fig/></Fruits>
. That's not too bad, if in fact they are empty elements, but if they have long complicated contents (and especially if two different instances of Cherry could give different, i.e. conflicting, information), it may seem too dangerous or confusing.
You could add a Schematron layer of validation and add an assertion that Fruits has at least one child (if you stay with your initial sketch) or that Fruit has at most one child of any variety (if you go with the nested-choice approach).