Consider a transform like this:

<xsl:template match="/">
  <xsl:for-each select="1 to 5">
    <xsl:result-document href="out{.}.xml">
      <out/>
    </xsl:result-document>
  </xsl:for-each>
</xsl:template>

The transformation produces 5 secondary output documents, but we need to ask whether it produces a primary output document (if it does, then it's empty)

F+O says of fn:transform:

<quote from="F+O 3.1">
The result of the transformation is returned as a map. There is one entry in the map for the principal result document, and one for each secondary result document. The key is a URI in the form of an xs:string value. The key for the principal result document is the base output URI if specified, or the string "output" otherwise.
</quote>

But we have tests (for example fn-transform-33) that assume there will be no entry in the map for the principal result document if it is empty. This is justified by the XSLT 2.0 specification, which states: 

<quote from="XSLT 2.0 §2.4">
An implicit result tree is also created when the result sequence is empty, provided that no xsl:result-document instruction has been evaluated during the course of the transformation. In this situation the implicit result tree will consist of a document node with no children.

Note:

This means that there is always at least one result tree. It also means that if the content of the initial template is a single xsl:result-document instruction, as in the example above, then only one result tree is produced, not two. It is useful to make the result document explicit as this is the only way of invoking document-level validation.
</quote>

It's hard to interpret what the F+O statement "There is one entry in the map for the principal result document" means in the case where there is no principal result document.

And XSLT 3.0 changes the rules:

<quote from="XSLT 3.0 §2.3.6.2">
In previous versions of this specification it was stated that when the raw result of the initial template or function is an empty sequence, a result tree should be produced if and only if the transformation generates no secondary results (that is, if it does not invoke xsl:result-document).... Processor APIs offering backwards compatibility with earlier versions of XSLT must respect this behavior, but there is no requirement for new processor APIs to do so.
</quote>

Given these differences, I think it would be best if we tolerate diversity:

(a) the spec should say that it's implementation-defined whether the result map returned by fn:transform() contains an entry in respect of the principal result document in the case where the principal result is empty or absent.
 
(b) the relevant tests should be changed to allow the principal result to be either present or absent.

Affected tests are:

fn-transform-33
  fn-transform-37
  fn-transform-38
  fn-transform-39
  fn-transform-40
  fn-transform-43
  fn-transform-44
  fn-transform-46
  fn-transform-err-10
  fn-transform-err-11