I'm sorry, I don't understand the problem.

Using the same package twice is exactly the same as using two different packages with the same content. You're very likely to get a 3050 if you use the same package twice, but you can avoid it if you are very careful in what you accept. I don't see any rule in 3.5.3.2 that suggests your example should not be allowed, assuming of course that the used package consists entirely of functions.

In response to your final sentence, I'm not sure what you mean by "the component". The first use-package creates a component corresponding to every component in urn:use-me; the second use-package creates another component corresponding to every component in urn:use-me; a 3050 occurs if this results in two non-hidden components with the same name.

For the sake of argument, let's assume the package has only one function, pkg:function1.

Then we have two lines in two xsl:use-package:

1) <xsl:accept component="function" names="pkg:function1" visibility="hidden" />
2) <xsl:accept component="function" names="pkg:function1" visibility="public" />

(1) hides pkg:function1 from the scope of the using package
(2) unhides (?) pkg:function1 and brings it in scope of the using package

The question I'm wondering about is whether we (dis)allow this correctly. And in the case this does NOT raise an error (I think it does not), is the declaration order then the definitive rule? Or highest/lowest visibility in the cumulation of all xsl:accept?

I think that XTSE3050 says, with "other than hidden", that:

a) the first line is "hidden" for component pkg:function1
b) the second line is "public" for the same component
c) the names are homonymous, but one is hidden
d) so this error should NOT raise

Btw, we say "two or more homonymous components", do we explicitly mean two such components from different (physical) packages, or may they be the result of using the same package twice (as in this case)?

Perhaps we don't make it clear enough, but I think that "using" the same package twice should behave exactly like "using" two different packages that have identical content.

Although this doesn't matter too much for this trivial case, it becomes very important for "diamond" structures where the same package is imported indirectly by two different routes.

The using package gets the union of the sets of components from all the xsl:use-package declarations, and there's an error if this union contains non-hidden name-clashes. In this case the union contains no clash: the using package has one public component named pkg:function1 from the first use-package, and one hidden component named pkg:function1 from the second use-package. Declaration order is not relevant.

> In this case the union contains no clash: the using package has one public 
> component named pkg:function1 from the first use-package, and one hidden 
> component named pkg:function1 from the second use-package. Declaration order 
> is not relevant.
Maybe I misunderstand, but do you mean that there is now a hidden pkg:function1 and a public pkg:function1 that happens to be the same function?

But doesn't that clash with the name resolution? We try to find a component, and we may find the hidden component by that name before we find the public component. If we find the hidden component first, we have to raise an error.

Though I would argue that there are not two components here, but only one, that is either hidden or public (Schrödinger's Cat anyone?).

As discussed on the telcon of June 2, 2016, the WG concluded that it would be helpful to add a Note at editor's discretion to explain that using two packages with the same name is the same as using two packages with a different name but with the same content.

Perhaps a better way of stating this is to explain that:

  <xsl:use-package name="urn:package1" package-version="1.0"  >
    <xsl:accept component="function" names="pkg:function1" visibility="hidden" />
  </xsl:use-package>

  <xsl:use-package name="urn:use-me" package-version="*"  >
    <xsl:accept component="function" names="pkg:function1" visibility="public" />
  </xsl:use-package>

and 

  <xsl:use-package name="urn:package1" package-version="1.0"  >
    <xsl:accept component="function" names="pkg:function1" visibility="hidden" />
    <xsl:accept component="function" names="pkg:function1" visibility="public" />
  </xsl:use-package>

are NOT the same (the first is correct, albeit useless, the second will raise an error). My line of thought that prompted this bug-report is that we create a UNION of all xsl:use-package with the same name. This is not true.

We may also want to stress that declaration order is not relevant here. A subsequent declaration does NOT hide a previous declaration and will likely cause errors (this is different from some other declarations).

I have added a test case override-f-031

Correction, the new test override-f-031 is a for bug #29686

Completing the action identified in comment #5, I have added the following note at the end of section 3.5.2:

<note>
<p diff="add" at="T-bug29667">It is not intrinsically an error to have two 
<elcode>xsl:use-package</elcode> declarations that identify the same package
(or different versions of the same package). This has the same effect as
having two declarations that identify packages with different names but
identical content. In most cases it will result in an error (<errorref spec="XT" class="TE" code="3050"/>)
due to the presence of multiple components with the same name; but 
no error would occur, for example, if the used package is empty, or if the 
two <elcode>xsl:use-package</elcode> declarations use <elcode>xsl:accept</elcode>
to accept non-overlapping subsets of the components in the used package.</p>
</note>

That appears to me to perfectly cover it. Thanks.

The addition was accepted by the WG.