Created attachment 4239 [details]
Case test file showing the problem

Is it with or without -dSAFER?

I don't use -dSAFER, then I would say without it.

It is true that most setpagedevice commands have no effect on the pxl driver
once BeginPage has started.

Assigning to Henry who owns the pal devices.

Yes without special provision no vector devices (gdevvec.h) will support this kind of behavior, I don't see any use for it in PXL and it would be quite difficult to implement.  If the file is changed all the active resources would have to be brought over to the new file.  Similarly pxlcolor and pxlmono do not support the popular ghostscript %d page number option for basically the same reason.  See the put_params comment in gdevvec.c:

    switch (code = param_read_string(plist, (param_name = "OutputFile"), &ofns)) {
        case 0:
            /*
             * Vector devices typically write header information at the
             * beginning of the file: changing the file name after writing
             * any pages should be an error.
             */
            if (ofns.size > fname_size)
                ecode = gs_error_limitcheck;
...

Anyway I copied Ken in as it might be a curious file to try out with pdfwrite - a vector device which has recently been modified to do interesting things at page boundaries, but this is not a bug.

 I don't believe OutputFile is part of the Adobe Spec is it?

I must have missed this one when first reported....

Henry is correct that OutputFile is not a standard key in the page device dictionary, so it behaviour is entirely at our discretion. 

As to our ignoring a change in value being contrary to the specification, the PLRM (3rd Edition) is quite clear:

"The operand to setpagedevice is a request dictionary whose entries specify
desired settings or values for one or more page device parameters.

...

Note that the entries in the request dictionary
are merely requests for certain parameter settings; depending on the capabilities
of a given page device, these requests may or may not be honored"

So all entries in the page device dictionary are entirely device dependent and it is entirely legal to ignore a request. 

In fact its even reasonable to process a request up to a certain point, and ignore subsequent ones. As an example consider Binding, it might well be possible for a device to bind either on the right or the left, but once you've started binding on one side, you can't realistically change to the other without starting a new job.

With pdfwrite this file results in a single page blank PDF file. Presumably the content is directed elsewhere, I have no idea where its going and am not keen on spending time trying to find out.

I did just check this, and discovered that, *because* we are changing device from pdfwrite to pxlmono and then back to pdfwrite (save and restore in the job), the PCL files are created as expected, in the current working directory.

So if you really want this kind of behaviour that's one way to achieve it but note that this *only* work because we are switching devices with each setpagedevice.

If you set the device to pdfwrite in the PostScript it does appear to cope with this, and writes (PDF) files with the correct names.

Ok. I've found the relevant "note" from the Adobe specs and I too have to agree this vector devices behaviour is not in contrast with them.

Anyway, one would expect (rigtly or not) that the setdevice dictionary entries defined for a specific device would apply at the same time.

Can't the behaviour outlined by Ken in "switching" from one device type to another and then back to the first be somehow "emulated" in much more efficent manner by vector devices when a non-page-wide setpagedevice attribute gets changed?