encode-for-uri() and filenames?

Dear XProc Dev,

I've been struggling with filenames that are not compatible with URIs, and
attempting to work around the limitation by using encode-for-uri() when I
save the file. I described the general problem on the eXist-open mailing
list, so I won't repeat it here, but my issue has an XProc aspect, and may
even be an XProc—rather than broader filename—issue, and I would be
grateful if someone on this list to help clarify that aspect of it for me.

Here is a test XProc file, which I run under MorganaXProc-IIIse
0.9.4.8-beta:

<?xml version="1.0" encoding="UTF-8"?>
<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" xmlns:c="
http://www.w3.org/ns/xproc-step"
  version="3.0">
  <p:input port="source">
    <p:inline>
      <doc>Hello world!</doc>
    </p:inline>
  </p:input>
  <p:output port="result"/>
  <p:variable name="output-filename"
select="encode-for-uri('test-1a%7%.xml')"/>
  <p:identity message="{$output-filename}"/>
  <p:store href="{$output-filename}"/>
  <p:identity/>
</p:declare-step>


Because the percent signs as they are used in the filename are incompatible
with URI encoding, I expect them to be percent-encoded themselves, with the
modified filename echoed to stderr (in the <p:identity> step) and used to
save the test file (in the <p:store> step). What happens instead is that
the percent encoded value is written, as expected, to stderr:

test-1a%257%25.xml


but the file is saved to the local filesystem as if encode-for-uri() had
not been applied, that is, as:

test-1a%7%.xml


What I expected instead is that the filename used to save the output to the
local filesystem would match the percent-encoded value displayed in the
<p:identity> step.

For what it's worth, if I run encode-for-uri() twice (nested) on the
filename, the stderr result is twice percent-encoded
(test-1a%25257%2525.xml) and the filename as written by the <p:store> step
is singly percent-encoded (test-1a%257%25.xml).

This all seems to suggest that 1) encode-for-uri() works, and 2) it is
possible to use the output of an encode-for-uri() call to create a
filename. But it looks as if the filename as used by the <p:store> step
undoes one instance of encode-for-uri()—the only instance in the example
above and the second (wrapping) instance in the "for what it's worth"
experiment below that. What I expected was that the filename used by
<p:store> would be the same as the value specified for the @href attribute
and written to stderr in the <p:identity> step. Have I misunderstood how
<p:store> works with filenames?

Sincerely,

David