cytan,
As Matt pointed, an application printing to CUPS controls only the format of the input. It has no direct control over the chain of filters inside the printing pipeline. Acrobat isn't coded to use pstoraster, it is simpling submitting postscript to the print queue. In an un-molested Apple supplied CUPS setup, that works fine.
What is going on is that the CUPS system configuration got mangled by some third party bits. In the Unix tradition, the configuration is fairly transparent, in the form of plain text files. In particular, in /usr/share/cups/mime you will find out exactly how the filter pipeline is configured via a table of what filter to use to convert data between two mime types. So we can inspect how the filters are setup and how a broken pstoraster is getting into the chain.
I don't have a handy "before mangling" state, but I can clearly see the Apple specified filters to be invoked when the input data is application/postscript (in apple.convs). I can also see a conflicting filter definition referencing the broken pstopdf (in mime.convs) but with a higher precedence, overriding the apple specified filter. This is why, in reference to your points #1 and #2, simply removing pstoraster fails, because the filter configuration is what needs fixing.
On my system, I found the pstoraster filter to be a shell script referencing a MacPorts install of ghostscript. I've since removed MacPorts, but that evidentally left the CUPS configuration in this broken state. Without knowing exactly how the CUPS system was put into the broken state, fixing it can be a bit tricky. Another posting suggested replacing the broken pstoraster with the Apple supplied equivalent of pstocupsraster. That might work, but it would be better to simply remove the conflicting filter specification, which on my system is this bit in /usr/share/cups/mime/mime.convs:
# pstoraster is part of GPL Ghostscript...
application/vnd.cups-postscript application/vnd.cups-raster 100 pstoraster
Removing that will restore the Apple specified filter chain for postscript input. With the filter specification gone, you are free to remove the pstoraster filter itself.
On wating for Adobe to fix this...
Acrobat provides enough things to scream about without pinning non-Acrobat problems on it as well. Not only is this problem not the fault of Acrobat, but suggesting that Acrobat should reach into a CUPS system broken by some unknown third party and fix it is only going to complicate the situation by having two third party products trying to un-do each other's configuration of a system resource. Do you really trust Adobe to fiddle with system components it doesn't own? No, I didn't think so. Adobe installers and updaters have enough trouble with the stuff they do own.
So, why does this problem only seem to affect Acrobat (your point #3)? I suspect it is simply that Acrobat is in the minority of submitting Postscript to the print queue. Any print job produced via CoreGraphics APIs is going to enter the system via a different path (namely, PDF), but the Postscript method is completely legitimate and any application that submits Postscript will be affected in the same way as Acrobat.
I hope this sheds some useful light on what is really going on with this problem.
-john
