There is discussion about deprecating the "pswrite" output device and replacing
it by the "ps2write" output device on the Ghostscript developer mailing list.
This does not cause any problem when the output data stream is directly sent to
the printer without further manipulation.

In certain cases the generated PostScript needs still to be processed before it
goes to a printer. This is especially needed by the new PDF-based printing
workflow which we are currently introducing under Linux. Applications are
sending PDF data and CUPS is doing the page management (N-up, selected pages,
...) on a PDF data stream. If the printer is a native PostScript printer, one
needs a PostScript printer driver now which is a filter which at first converts
PDF to PostScript (using Ghostscript with a PostScript output device, "pswrite"
or "ps2write") and then inserts the PostScript code snippets from the PPD file
depending on the option settings supplied as PPD defaults and job attributes.
This PostScript code insertion requires that the PostScript output of
Ghostscript is DSC-conforming. Therefore I am currently using the "pswrite"
device and "ps2write" is unsuitable for me.

So "pswrite" can only be removed from Ghostscript if "ps2write" produces
DSC-conforming Postscript. I recommend to have full DSC-conformance, as there
can always be users with other use cases than the case mentioned above. At the
very least the PostScript output should pass the test of "cupstestdsc" of the
current version of CUPS (1.3.8 at the day when this bug report was created). 

This is really an enhancement request

This is a duplicate of bug #688495.

*** This bug has been marked as a duplicate of 688495 ***