I'm seeing this differently than you are. The query in question is:

declare updating function 
             local:delete-subtree($p as element(part))
  {
      for $child in $part-list//part
      where $p/@partid eq $child/@partof
      return (
        local:delete-subtree($child),
        delete node $child
      )
  };

local:delete-subtree($part-list//part[@name="car"])


I'm guessing that the inferred type of the expression in the initial invocation of delete-subtree, element(part)*, is the problem.  This does not match the declared type of the parameter. I'd suggest fixing this by changing the function definition to:

declare updating function 
             local:delete-subtree($p as element(part)*)
  {
      for $child in $part-list//part
      where $p/@partid = $child/@partof
      return (
        local:delete-subtree($child),
        delete node $child
      )
  };


If you agree, then I'll make the change and then file this as a bug against the Update Facility Use Cases.

Please disregard my response in comment #1. I was confused by a mismatch between the query in the test suite:

local:delete-subtree($part-list//part[@name="car"])

and the query in the Use Cases document:

for $p in doc("part-list.xml")//part[@name="car"]
return 
  local:delete-subtree($p)


I've updated the test suite to bring them into sync.

I've reported your concern about the type of the $p parameter in Bug #6288.

The Working Group discussed this issue at its meeting today. We concluded
that after Andrew's change (reported in comment #2) to the test case query,
it now passes static type analysis.

However, this change deals with cardinality, whereas your proposed solution
deals with type annotations, so it seems unlikely that we have addressed
your original concern. If you think the amended query still fails static
type analysis, please provide more details as to why.

(By the way, 'element(part,xs:untyped)' is a strict subtype of
'element(part)', so it would seem that the only effect (if any) of
changing the parameter type as you suggest would be to *introduce*
a type error, not remove it.)

To answer the question in comment #3: "If you think the amended query still fails static type analysis, please provide more details as to why."

In the end this is similar to bug #2104

- the parameter $p is declared as "element(part)".
- $p/@partid is typed as attribute(partid, xs:anySimpleType)*
  (similar for $child/@partof)
- As a consequence, $p/@partid eq $child/@partof can statically compare incompatible types and should raise XPTY0004.

As such we see two options
a) adding XPTY0004 as a valid result
b) declaring the parameter as element(part, xs:untyped), will make the eq-comparison pass the static typing rules (This second alternative is obviously only viable assuming that the input document is "untyped" 

Thank you for claifying things in comment #4. I now agree with the problem
you raised initially: an XQuery implementation supporting the Static Typing
Feature (without type extensions) would be required to raise err:XPTY0004
during the static analysis phase, in respect of the expression
    $p/@partid eq $child/@partof
in XQUTS test case parts-q3-2. Sorry for not recognizing that earlier
in the discussion.

At its meeting on January 27th, the XQuery WG decided to resolve the bug
by leaving the query as is, and adding XPTY0004 as an expected result for
the test case. Consequently, we are marking this issue as resolved-FIXED.
If you agree with this resolution, please mark it CLOSED.

We agree with this resolution. Closing the issue.

The changes to the test suite have been checked into CVS.