I think my -1 for adding the new format was premature:  I was hoping to 
find a way to fix marshal for the 'unknown' format, but the cleanest 
solution does indeed appear to be to add the mixed-endian format.  And 
apart from the Python/compile.c oddity I can't find anywhere besides 
Objects/floatobject.c that needs to be changed, so the patch only has to 
touch one file.

Here's a reworked version of Aurelien Jarno's patch, against the trunk.  
The key differences, from more significant to less, are as follows:

- I've abstracted out the 3 different byte orders, so that the same code 
does the packing and unpacking for all 3 different formats.  I think 
things should be safer and more maintainable this way (and it makes life 
easier when some other wacky byteorder comes along).

- Rename the format to "IEEE, ARM mixed-endian".  Note that these mixed-
endian doubles are perfectly valid IEEE 754 doubles, so the name should 
start with "IEEE" so that the various IEEE 754-specific tests are enabled 
on ARM.  The IEEE 754 standard has precisely nothing to say about 
endianness or serialization of floats as byte sequences:   the words 
'endian', 'byte' and 'octet' don't even appear anywhere in the standard.

- In float.__setformat__, don't allow setting of "IEEE, ARM mixed-endian" 
for the 'float' type, only for the 'double' type.  (If I understand 
correctly, when the double type is ARM mixed-endian the float type will 
always be little-endian;  there are no mixed-endian single-precision 
floats to worry about.)

- whitespace cleanups, expanded comments and docstrings, and line length 
fixes.

I've tested this on two versions of OS X: 10.5.6/Intel (little-endian), 
and 10.4.10/PPC (big-endian), with no (new) test failures.

I fully expect that this patch will cause test failures on ARM as a result 
of the IEEE tests being enabled, but that's better than a build failure.  
If there's someone who's willing to provide feedback I'll work to fix 
those test failures.

I'm still not sure whether this can be a candidate 2.6 and 3.0.  Martin, 
do you have any thoughts on this?

To Mark Miller and Aurelien Jarno:  is either of you in a position to test 
this patch on the relevant mixed-endian platforms?