> it needs to be worded in a way that doesn't
> imply that the struct implementation is broken or misdesigned. 

Agree.

> A better note would focus on the basic (and obvious)
> fact that downgrading from double precision to single
> precision entails a loss of precision.

Sort of where I was going, but I'm sure my text could be vastly improved.

> The suggested examples are misleading because they 
> use 6.24 which is not exactly representable in binary
> floating point.

I'd quibble with this for two reasons:

1) to be precise, numbers which are not exactly representable in binary floating point would nonetheless pass the unpack(pack) test if you use the 'd' format character.  The key issue is, as you said, loss of precision.

2) I don't understand why the 6.24 example is "misleading" when it accurately demonstrates the issue.

One comment about portability I forgot to mention earlier:  I don't know how wed Python is to '754 or even binary floating point representations.  My personal belief is that it should be possible to write a test so that the unpack(fmt, pack(fmt, precision_truncate(number))) == precision_truncate(number) test works for any legal number on any platform.  I don't like the idea that one has to pick specific numbers based on knowledge of the platform's floating point format.

I acknowledge that this may not bother others as much as it bothers me though.  I'm a portability nut.