I am surprised that nobody has responded to this.  Apparently, nobody knows or if they do know, it seems they are unconcerned.  I have determined that getBytes does translate the character stream and I believe that serial write should not since most I/O to serial output is physically device oriented.  Or at least, provide an option to bypass the translation. 

Filling a String with all values ranging from 0x00 to 0xFF, then using string.getbytes() to create a byte array of those values, shows that values in the range 0x80 - 0x9F are translated to 0x3F for the default character set (U.S. anyway, others may see other values/ranges).  Thus, serial.write(String) should be removed or an alternative call provided that DOES NOT translate the values.

I don't see why serial.write(String) should be removed. I know nothing about the serial library, but it still looks useful to transmit textual data.
The problem seems to be that you want to force binary data to string format. But bytes above 0x7F are actually negative values, unsuitable for characters. Beside, Java uses 16bit chars, anyway.
You have serial.write(byte[]), why don't you use this one? (Again, just reading the doc., no idea of the technical issues.)

You are working on a bad assumption, in that the only data one would transmit to or receive from an Arduino is text data.  Hardly the case at all.  In fact, whether using the Firmata sketch on board, or some other sketch, binary data is most likely to be shipped via the serial library functions.  In the data construct for serial I/O, there are no such things as negative values (as one finds in the Processing language definition for byte).  There are only 8 bit data bytes, that may be used in whatever form is agreed upon by the sending and receiving programs. 

A String object is a convenient way to package data for sending to the Ardunio, but it has this trap where the data is obtained FROM the String by the serial I/O package by using the string.getBytes() function.  That call does a translate of the bytes. 

There is nothing wrong with (effectively) storing binary data in a String object.  In fact, all Processing strings are designed to hold binary data, as each character cell in a string is 16 bits wide to accomodate UNICODE specifications.  One rather nice thing about a String object is that is has a length which controls how much data is passed by serial.write(String). 

The proper technique is to use byte[] data but being an array, one must carefully manipulate the size of the array to be specific to the number of bytes sent.  And byte data is 8 bit values, as long as one does not get confused over the range (0 to 255, same as -128 to 127). 

Again, I suggested an alternative by providing a way to use String data but bypass the translation performed by getBytes().  Also, while Java does use 16 bit characters, serial.write() only uses the lower 8 bits (hence, the getBytes call). 

" You are working on a bad assumption, in that the only data one would transmit to or receive from an Arduino is text data"
No, since I was suggesting to use a binary alternative, among other things. I had the feeling it was you making this assumption...

" In the data construct for serial I/O, there are no such things as negative values (as one finds in the Processing language definition for byte)"
In the Java language, there is no such things as unsigned values. Except perhaps for char, which isn't really a numerical type.

" A String object is a convenient way to package data for sending to the Ardunio [...] There is nothing wrong with (effectively) storing binary data in a String object."
No. Quite the reverse: as you saw yourself, String has some issues, like handling encoding, often depending on current locale, perhaps rejecting invalid Unicode code points, etc.

" The proper technique is to use byte[] data but being an array, one must carefully manipulate the size of the array to be specific to the number of bytes sent"
Exactly. And this size handling is well worth the time spent on it, rather than struggling with the encoding issues of String...

Don't apply C techniques / hacks to Java. They have similar look, since Java syntax is rooted on C, but they also have subtle differences that can throw off. Java attaches more importance to the semantic value of the data, a String isn't used to hold binary data, 0 and 1 are not proper boolean values, etc. You have to adapt data when Java communicates with C, but by being careful about these differences.
" In fact, all Processing strings are designed to hold binary data, as each character cell in a string is 16 bits wide to accomodate UNICODE specifications."
No. The Unicode spec. precisely define invalid binary ranges...

I give...