Major Description
The fn:count function, when called on a path expression that ends with a unique scalar element, should be an SDE.
Such a call can only return value 1, or cause a processing error if the element doesn't exist. Existance should be tested with fn:exists(...).
If the schema really does have
<element name="foo" minOccurs="0" .../> <element name="bar" .../> <element name="foo" maxOccurs="5" .../>
and an expression has `fn:count(..../foo)` we already are giving an SDE about query-style expressions not being supported.
If the schema does not have this issue (multiple declarations of same element name), then fn:count() makes no sense when called on a scalar, and it should be an SDE if the path is not for an array or optional element.
My experience thusfar is that use of fn:count( ...) with a non-array, non-optional element path is always a mistake by the schema author.
Changing elements from array/optional to scalar is actually fairly common.
One decides rather than be an array, an element should instead contain the array as a child element, but now any fn:count(....) referring to the original array element is incorrect, as it now refers to the scalar element that contains the array as a child element. The schema compiler needs to help find these erroneous references.
Personally, I think calling fn:count(...) on a non-array/non-optional should be an SDE, but....
(This added... Was a fragment sentence initially) ... it may have to be a SDW with a tunable to make it an SDE, since we may find out that there are schemas depending on this returning 1 when called on scalar elements that would be broken by making it an SDE.
I suggest just making this an SDE first, and then we can see if it needs to be backed off to an SDW for some schemas.