This is a bug report that covers the unresolved part of https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Sep/0036.html and https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Sep/0039.html (member only) and related mail discussion.

Summary of that part:

The XSLT30 LCWD (Oct 2014) says that when you override an xsl:function and that function has override-extension-functions="no", then the overriding function must also specify override-extension-functions="no".

Use-case summary:

Package A:
<xsl:function name="exsl:random-sequence" 
    override-extension-functions="no">
    <!--
       custom implementation, but if exsl:random-sequence (EXSLT.org)
       is supported, then processor should use internal version
     -->
</xsl:function>

Package B:
<xsl:override>
    <xsl:function name="exsl:random-sequence" 
       override-extension-functions="yes">
       <!-- 
          User wants to make use of the new fn:random-sequence of XP31
          implementation using XPath 3.1 random sequence
        -->
    </xsl:function>
</xsl:override>

Result:
[ERR XTSE3070] It is a static error if the signature of an overriding component is not compatible with the signature of the component that it is overriding.

Relevant spec part:

Definition of "compability": https://www.w3.org/XML/Group/qtspecs/specifications/xslt-30/html/Overview-diff.html#dt-compatible (member only), item 4 of the second bullet:

<quote>
If the overridden function specifies override-extension-functions="no" (or the equivalent using the deprecated override attribute) then the overriding function also specifies override-extension-functions="no" (or the equivalent).
</quote>

Proposed solution:

Remove this rule (not the error), because it limits users choosing to switch to (new) internal XPath 3.1 or later, or XSLT 3.x or later functions as a preference over internal implementations and as such, limits extensibility and more importantly, inter-processor compatibility.